There's a new qdisc on the block. Here's some documentation on how it works.<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">John Fastabend</b> <span dir="ltr"><<a href="mailto:john.r.fastabend@intel.com">john.r.fastabend@intel.com</a>></span><br>
Date: Mon, May 9, 2011 at 11:22 AM<br>Subject: Re: trying to wrap my head around mqprio<br>To: Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>><br><br><br><div><div></div><div class="h5">On 5/8/2011 12:49 AM, Dave Taht wrote:<br>

> I just finished backporting sfb into openwrt and was looking around<br>
> at iproute2 when I noticed mqprio was in there now.<br>
><br>
> Is there any doc on how this works? I'm about to run a big test of a<br>
> few dozen debufferbloated wireless routers and eBDP hasn't been going<br>
> so well.....<br>
><br>
> -- Dave Täht SKYPE: davetaht US Tel: <a href="tel:1-239-829-5608" value="+12398295608">1-239-829-5608</a><br>
</div></div>> <a href="http://www.bufferbloat.net" target="_blank">http://www.bufferbloat.net</a> <<a href="http://the-edge.blogspot.com" target="_blank">http://the-edge.blogspot.com</a>><br>
<br>
<br>
Hi Dave,<br>
<br>
Currently, there is no documentation. I should write a tc-mqprio<br>
man page I'll try to get to this soon.<br>
<br>
This qdisc was created to support hardware offloaded QOS. Today<br>
a lot of hardware supports various QOS schemes. Mostly these<br>
are 802.1Q transmission selection algorithms specifically<br>
strict priority seems common enough and a few more support<br>
ETS part of the 802.1Qaz spec (colloquially referred to as DCB).<br>
<br>
The driver typically assigns queues to different traffic classes<br>
in hardware. The problem I was trying to address with this qdisc<br>
was expose the mapping of queues onto traffic class to the QOS layer<br>
so we had a mechanism to steer skbs towards the correct hardware<br>
queues based on priority. Previously drivers were using select_queue()<br>
to do this or administrators were building implicit mappings<br>
in QOS using multiq qdisc because they happened to know some<br>
specifics about the hardware. This was error prone especially<br>
when the number of queues and mappings were not static.<br>
<br>
As it stands now applications can set the priority with SO_PRIORITY<br>
or set the mark with SO_MARK. Then ip rules can set the priority<br>
based on the mark and the priority will get directly mapped into<br>
a queue set associated with a traffic class in hardware.<br>
<br>
The mqprio netlink interface allows using a driver callback ndo_setup_tc()<br>
to allow the driver to configure the device or the user can<br>
override the driver defaults and assign whatever mappings they would<br>
like. If you do this I expect you understand the hardware well enough<br>
to know the hardware limitations. For example the Intel 82598 card<br>
only supports 1 or 8 traffic classes but nothing in between.<br>
<br>
Hope this helps.<br>
<br>
Thanks,<br>
<font color="#888888">John.<br>
</font></div><br><br clear="all"><br>-- <br>Dave Täht<br>SKYPE: davetaht<br>US Tel: 1-239-829-5608<br><a href="http://the-edge.blogspot.com" target="_blank">http://the-edge.blogspot.com</a> <br>