[ovs-discuss] QoS Queues on wireless interfaces

Matthias May matthias.may at neratec.com
Wed Sep 18 22:49:34 UTC 2019

On 18/09/2019 16:41, Calvin.Schmidt at web.de wrote:
> Hi all,
> I tried configuring queues with OpenFlow on ethernet interfaces and it worked just fine.
> However if I set a specific queue on a flow with the set_queue action that outputs the packet to a wireless interface, it somehow is ignored and the default queue 0 is taken. I can set a certain bandwith on queue 0 and therby limit the bandwith however this is not sufficient for my use case.
> I've run the following commands:
> 1. Create the QoS and Queues on wireless interface wlan0
> ovs-vsctl -- set port wlan0 qos=@newqos -- --id=@newqos create qos type=linux-htb queues:1=@newqueue queues:2=@newqueue2 -- --id=@newqueue create queue other-config:min-rate=3000000 other-config:max-rate=3000000 -- --id=@newqueue2 create queue other-config:min-rate=8000000 other-config:max-rate=8000000
> 2. Check the Queues have been created
> ovs-ofctl queue-get-config ovsbr wlan0 -O OpenFlow13
> 3. Create a flow that uses Queue 1 for HTTPS traffic
> ovs-ofctl add-flow ovsbr priority=1,dl_type=0x800,nw_proto=6,tp_src=443,in_port="eth0.2",actions=set_queue:1,output:"wlan0" -O OpenFlow13
> 4. Check the flow has been created and packets are processed by it
> ovs-ofctl dump-flows ovsbr -O OpenFlow13
> 5. Check if traffic is going through Queue 1 (unfortunately not)
> ovs-ofctl queue-stats ovsbr -O OpenFlow13
> So my questions are:
> 1. Is it possible to have multiple queues on a wireless interface that are managed by a set of flows?
> 2. What do I have to do to make it work?
> I found this thread which seems to be related to the issue as well however I do not quite get it: https://mail.openvswitch.org/pipermail/ovs-discuss/2013-August/030714.html
> Any help is highly appreciated.
> Thanks and kind regards,
> Calvin
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


I observed the same.
See the thread at

At least in ath9k the idea is to map the skb-priority directly to the
queues according to 802.1d.
Since ovs does this strange/undocumented offset of 0x10000 I ended up
going a different path.
I ended up using something along the line of
And patching ath9k to map these skb-marks to the queues according to my


More information about the discuss mailing list