From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 11E4220175B for ; Mon, 9 May 2011 11:32:23 -0700 (PDT) Received: by iwn8 with SMTP id 8so7011710iwn.16 for ; Mon, 09 May 2011 11:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=aFtlN7Zl8TN3E6gKR9O5obUfpH+d6TprCqTa0b7aMdk=; b=FBU3undIDYMSGovB1IzvlgWcItOU0q0mVN/I8QlqyVLgkXHwSutYssDGOZKKwhfnj1 fCyF8EshdrFzg+cG2AMbnTKhFLXex7q0q0r4yaOjCbaezEoFd4MIo/+0Vm7nubNoLG28 RLY13oYQX5VD8Si11Z/Jsxa6tVeg3fWD5VBbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CdDupto5p5GUoT5hvgsU2EXLIxDGNJTEdwboUp4xgY6CcexHJyA4yFCdpkpLRGkK0X Ep82mZ4Bd0J63FsBlXxV2aTNg3dQ03CEaVTYuqLPggRpaIfIgdZ9TGcHbXdUlR1YS+tv FnbL7PXE9wOcrWiFchVE5Gme3FzT6XyM4ANRE= MIME-Version: 1.0 Received: by 10.231.69.198 with SMTP id a6mr1449759ibj.181.1304966330721; Mon, 09 May 2011 11:38:50 -0700 (PDT) Received: by 10.231.31.201 with HTTP; Mon, 9 May 2011 11:38:50 -0700 (PDT) Date: Mon, 9 May 2011 12:38:50 -0600 Message-ID: From: Dave Taht To: bloat Content-Type: multipart/alternative; boundary=0015176f1300962a8404a2dc261c Subject: [Bloat] Some mqprio documentation X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 18:32:24 -0000 --0015176f1300962a8404a2dc261c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There's a new qdisc on the block. Here's some documentation on how it works= . ---------- Forwarded message ---------- From: John Fastabend Date: Mon, May 9, 2011 at 11:22 AM Subject: Re: trying to wrap my head around mqprio To: Dave Taht On 5/8/2011 12:49 AM, Dave Taht wrote: > I just finished backporting sfb into openwrt and was looking around > at iproute2 when I noticed mqprio was in there now. > > Is there any doc on how this works? I'm about to run a big test of a > few dozen debufferbloated wireless routers and eBDP hasn't been going > so well..... > > -- Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 > http://www.bufferbloat.net Hi Dave, Currently, there is no documentation. I should write a tc-mqprio man page I'll try to get to this soon. This qdisc was created to support hardware offloaded QOS. Today a lot of hardware supports various QOS schemes. Mostly these are 802.1Q transmission selection algorithms specifically strict priority seems common enough and a few more support ETS part of the 802.1Qaz spec (colloquially referred to as DCB). The driver typically assigns queues to different traffic classes in hardware. The problem I was trying to address with this qdisc was expose the mapping of queues onto traffic class to the QOS layer so we had a mechanism to steer skbs towards the correct hardware queues based on priority. Previously drivers were using select_queue() to do this or administrators were building implicit mappings in QOS using multiq qdisc because they happened to know some specifics about the hardware. This was error prone especially when the number of queues and mappings were not static. As it stands now applications can set the priority with SO_PRIORITY or set the mark with SO_MARK. Then ip rules can set the priority based on the mark and the priority will get directly mapped into a queue set associated with a traffic class in hardware. The mqprio netlink interface allows using a driver callback ndo_setup_tc() to allow the driver to configure the device or the user can override the driver defaults and assign whatever mappings they would like. If you do this I expect you understand the hardware well enough to know the hardware limitations. For example the Intel 82598 card only supports 1 or 8 traffic classes but nothing in between. Hope this helps. Thanks, John. --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --0015176f1300962a8404a2dc261c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There's a new qdisc on the block. Here's some documentation on how = it works.

---------- Forwarded message --= --------
From: John Fastabend <john.r.fastaben= d@intel.com>
Date: Mon, May 9, 2011 at 11:22 AM
Subject: Re: trying to wrap my head a= round mqprio
To: Dave Taht <da= ve.taht@gmail.com>


On 5= /8/2011 12:49 AM, Dave Taht wrote:
> I just finished backporting sfb into openwrt and was looking around > at iproute2 when I noticed mqprio was in there now.
>
> Is there any doc on how this works? I'm about to run a big test of= a
> few dozen debufferbloated wireless routers and eBDP hasn't been go= ing
> so well.....
>
> -- Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608
> h= ttp://www.bufferbloat.net <http://the-edge.blogspot.com>


Hi Dave,

Currently, there is no documentation. I should write a tc-mqprio
man page I'll try to get to this soon.

This qdisc was created to support hardware offloaded QOS. Today
a lot of hardware supports various QOS schemes. Mostly these
are 802.1Q transmission selection algorithms specifically
strict priority seems common enough and a few more support
ETS part of the 802.1Qaz spec (colloquially referred to as DCB).

The driver typically assigns queues to different traffic classes
in hardware. The problem I was trying to address with this qdisc
was expose the mapping of queues onto traffic class to the QOS layer
so we had a mechanism to steer skbs towards the correct hardware
queues based on priority. Previously drivers were using select_queue()
to do this or administrators were building implicit mappings
in QOS using multiq qdisc because they happened to know some
specifics about the hardware. This was error prone especially
when the number of queues and mappings were not static.

As it stands now applications can set the priority with SO_PRIORITY
or set the mark with SO_MARK. Then ip rules can set the priority
based on the mark and the priority will get directly mapped into
a queue set associated with a traffic class in hardware.

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
override the driver defaults and assign whatever mappings they would
like. If you do this I expect you understand the hardware well enough
to know the hardware limitations. For example the Intel 82598 card
only supports 1 or 8 traffic classes but nothing in between.

Hope this helps.

Thanks,
John.



--
Dave T=E4ht
SKYPE: davetah= t
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--0015176f1300962a8404a2dc261c--