Re: Using queueing on asynchronous interface

[Kaya Saman]

On 07/27/2017 05:30 PM, Stuart Henderson wrote:

On 2017-07-26, Kaya Saman  wrote:

[snip]

I'm finding that I don't really need much in the way of "downstream"
queueing though. It might be needed in special cases but using mikeb's
shiny new fq-codel code in -current, one single queue definition on the
upstream interface is keeping traffic flowing nicely.

queue hfsq-em1 on em1 flows 1024 bandwidth $BW_ZEN max $BW_ZEN quantum 400 
qlimit 1000 default

Is fq_codel already implemented in -current yet?

Yes.


I just grabbed the latest snapshot but can't find the files in the
sys/net directory??

https://github.com/openbsd/src/tree/master/sys/net

https://github.com/openbsd/src/commits/master/sys/net/fq_codel.c
(and other files).




Sorry if I wasn't clear... I was trying to say that I don't have those 
files:


fq_codel.c
fq_codel.h

in my sys/net directory:

# ls |sort
CVS
bpf.c
bpf.h
bpf_filter.c
bpfdesc.h
bridgestp.c
bsd-comp.c
ethertypes.h
hfsc.c
hfsc.h
if.c
if.h
if_aoe.c
if_aoe.h
if_arp.h
if_bridge.c
if_bridge.h
if_dl.h
if_enc.c
if_enc.h
if_ethersubr.c
if_gif.c
if_gif.h
if_gre.c
if_gre.h
if_llc.h
if_loop.c
if_media.c
if_media.h
if_mpe.c
if_pflog.c
if_pflog.h
if_pflow.c
if_pflow.h
if_pfsync.c
if_pfsync.h
if_ppp.c
if_ppp.h
if_pppoe.c
if_pppoe.h
if_pppvar.h
if_pppx.c
if_sl.c
if_slvar.h
if_sppp.h
if_spppsubr.c
if_trunk.c
if_trunk.h
if_tun.c
if_tun.h
if_types.h
if_var.h
if_vether.c
if_vlan.c
if_vlan_var.h
if_vxlan.c
if_vxlan.h
netisr.c
netisr.h
pf.c
pf_if.c
pf_ioctl.c
pf_lb.c
pf_norm.c
pf_osfp.c
pf_ruleset.c
pf_table.c
pfkey.c
pfkeyv2.c
pfkeyv2.h
pfkeyv2_convert.c
pfkeyv2_parsemessage.c
pfvar.h
pipex.c
pipex.h
pipex_local.h
ppp-comp.h
ppp-deflate.c
ppp_defs.h
ppp_tty.c
radix.c
radix.h
radix_mpath.c
radix_mpath.h
raw_cb.c
raw_cb.h
raw_usrreq.c
route.c
route.h
rtsock.c
slcompress.c
slcompress.h
slip.h
trunklacp.c
trunklacp.h

which is odd - maybe I updated from a mirror which hadn't been sync'ed 
yet with the latest. Just checked the "snapshots" directory and looks 
like it got updated today so will try again now  :-)


Thanks again Stuart for all your help!

Regards,

Kaya

Re: Using queueing on asynchronous interface

[Stuart Henderson]

On 2017-07-26, Kaya Saman  wrote:
>
> [snip]
>> I'm finding that I don't really need much in the way of "downstream"
>> queueing though. It might be needed in special cases but using mikeb's
>> shiny new fq-codel code in -current, one single queue definition on the
>> upstream interface is keeping traffic flowing nicely.
>>
>> queue hfsq-em1 on em1 flows 1024 bandwidth $BW_ZEN max $BW_ZEN quantum 400 
>> qlimit 1000 default
>
> Is fq_codel already implemented in -current yet?

Yes.

> I just grabbed the latest snapshot but can't find the files in the 
> sys/net directory??
>
> https://github.com/openbsd/src/tree/master/sys/net

https://github.com/openbsd/src/commits/master/sys/net/fq_codel.c
(and other files).

Re: Using queueing on asynchronous interface

[Kaya Saman]

[snip]

I'm finding that I don't really need much in the way of "downstream"
queueing though. It might be needed in special cases but using mikeb's
shiny new fq-codel code in -current, one single queue definition on the
upstream interface is keeping traffic flowing nicely.

queue hfsq-em1 on em1 flows 1024 bandwidth $BW_ZEN max $BW_ZEN quantum 400 
qlimit 1000 default


Is fq_codel already implemented in -current yet?

I just grabbed the latest snapshot but can't find the files in the 
sys/net directory??


https://github.com/openbsd/src/tree/master/sys/net


Kaya

Re: Using queueing on asynchronous interface

[Kaya Saman]

Many thanks Stuart!



On 07/26/2017 11:37 AM, Stuart Henderson wrote:

On 2017-07-25, Kaya Saman  wrote:

My goal is to use a different queue for up/down were I can change the
max bandwidth accordingly.

Queuing is done outbound, your "in" queues actually need to be on the
outbound interfaces. The trick is that "queue foo on em0" and "queue foo
on em1" are separate queues but traffic assignment is done using the
"foo" part. Don't try to split traffic between _in and _out queues.
The queue is stored with the PF state; the PF state covers traffic in
both directions. So you just want "somequeue", not "somequeue_in"
and "somequeue_out", and get rid of the received-on.


I have revised my queueing statements as you suggested and will 
definitely look further into adjusting them via your input.



I created a list of vlan interfaces called q_if though in one of the
links above Stuart Henderson doesn't advise it but the vlans are bound
to an lacp trunk with a group of physical interfaces

Generally I prefer simple failover for trunk, then this would be easy
(a separate queue on each physical interface - the interfaces don't need
to interact with each other, only one is used at a time).

If you must have load-balancing you could play with queueing on the trunk
interface rather than the physical ones, though I haven't tried this.


It's not really load-balancing that is needed but rather a solution to 
allow for extra throughput-bandwidth when needed. I find the trunk does 
go up to and over 2Gbps at times.




I'm finding that I don't really need much in the way of "downstream"
queueing though. It might be needed in special cases but using mikeb's
shiny new fq-codel code in -current, one single queue definition on the
upstream interface is keeping traffic flowing nicely.

queue hfsq-em1 on em1 flows 1024 bandwidth $BW_ZEN max $BW_ZEN quantum 400 
qlimit 1000 default


Fantastic! I will take a look at flows, quantum and qlimit and try to 
understand how these options affect the traffic.




(I am also throttling wifi per-user. OpenBSD's queueing isn't geared up
for that - with v4 you can sort-of do it with loads of separate per-IP
queues but it's horribly ugly, and no good at all for v6 - so I'm doing
that in the APs instead.)



Yeah... wifi is one of those connection types that can be a pain to get 
to function well. I'm going to have to revise my 802.11 setup at some 
point to go from "Standalone" AP's to a controller based solution for 
device handover etc...



Best Regards,

Kaya

Re: Using queueing on asynchronous interface

[Stuart Henderson]

On 2017-07-25, Kaya Saman  wrote:
> My goal is to use a different queue for up/down were I can change the 
> max bandwidth accordingly.

Queuing is done outbound, your "in" queues actually need to be on the
outbound interfaces. The trick is that "queue foo on em0" and "queue foo
on em1" are separate queues but traffic assignment is done using the
"foo" part. Don't try to split traffic between _in and _out queues.
The queue is stored with the PF state; the PF state covers traffic in
both directions. So you just want "somequeue", not "somequeue_in" 
and "somequeue_out", and get rid of the received-on.

> I created a list of vlan interfaces called q_if though in one of the 
> links above Stuart Henderson doesn't advise it but the vlans are bound 
> to an lacp trunk with a group of physical interfaces

Generally I prefer simple failover for trunk, then this would be easy
(a separate queue on each physical interface - the interfaces don't need
to interact with each other, only one is used at a time).

If you must have load-balancing you could play with queueing on the trunk
interface rather than the physical ones, though I haven't tried this.

I'm finding that I don't really need much in the way of "downstream"
queueing though. It might be needed in special cases but using mikeb's
shiny new fq-codel code in -current, one single queue definition on the
upstream interface is keeping traffic flowing nicely.

queue hfsq-em1 on em1 flows 1024 bandwidth $BW_ZEN max $BW_ZEN quantum 400 
qlimit 1000 default

(I am also throttling wifi per-user. OpenBSD's queueing isn't geared up
for that - with v4 you can sort-of do it with loads of separate per-IP
queues but it's horribly ugly, and no good at all for v6 - so I'm doing
that in the APs instead.)