From: Amir Vadai <amirv@mellanox.com>
To: John Fastabend <john.r.fastabend@intel.com>
Cc: Or Gerlitz <or.gerlitz@gmail.com>,
Ben Hutchings <bhutchings@solarflare.com>,
<netdev@vger.kernel.org>,
Yevgeny Petrilin <yevgenyp@mellanox.com>,
Oren Duer <oren@mellanox.com>,
Amir Vadai <amirv@dev.mellanox.co.il>,
Liran Liss <liranl@mellanox.com>
Subject: Re: [PATCH V2 4/7] net/mlx4_en: Set max rate-limit for a TC
Date: Tue, 27 Mar 2012 14:03:57 +0200 [thread overview]
Message-ID: <4F71ACAD.7010803@mellanox.com> (raw)
In-Reply-To: <4F70BB98.4090806@intel.com>
On 03/26/2012 08:55 PM, John Fastabend wrote:
> On 3/26/2012 10:00 AM, Or Gerlitz wrote:
>> On Mon, Mar 26, 2012 at 4:46 PM, Ben Hutchings
>> <bhutchings@solarflare.com> wrote:
>>>> We used sysfs since max bw isn't part of the ETS / DCBX NL support, and we're
>>>> open to other suggestions to add generic support for max bw, e.g add call to
>>>> the DCBX NL API.
>>
>>> netlink interfaces are generally easily extensible and it doesn't make
>>> sense to me to augment such an interface through sysfs. Perhaps you're
>>> concerned that netlink extensions won't be supported in older kernel
>>> versions running your OOT driver? That's unfortunate, but let's not
>>> standardise an ugly interface based on a temporary problem like that.
>>
>> As written above, that was done since ratelimit isn't part of ETS, we can
>> that through netlink extensions that you mentioned, if this is the preffered
>> way to go, David? Eric? Ben - could you provide pointer to these extensions?
>>
>> Or.
>> --
>
> I think I original suggested it didn't belong in DCBNL because it
> wasn't part of ETS (802.1Qaz). But it _is_ a traffic selection
> algorithm and could fall into the vendor specific part of 802.1Q.
>
> I would suggest either adding it as an option to mqprio to take
> a max bandwidth. The advantage here is it would be tied in with
> the usual QOS tooling 'tc'.
>
> # tc qdisc add dev eth3 root mqprio help
> Usage: ... mqprio [num_tc NUMBER] [map P0 P1 ...]
> [queues count1@offset1 count2@offset2 ...] [hw 1|0]
> [max_rate rate@tc ...]
>
This could be elegant, but since tc here is a logical traffic class and
ratelimit in our context is an attribute of ETS TC, it could be
problematic.
>
> Or extending DCBNL being careful not to break backwards
> compatibility. I tend to think extending mqprio is cleaner but
> a DCBNL extension could likely work as well. Would need a
> 'DCBNL_IEEE_SET_MAXRATE' and 'DCBNL_IEEE_GET_MAXRATE' for this
> I expect.
I do prefer this option. I'm checking now if it is possible to add
infrastructure for a vendor specific netlink command. It could be
connected by lldpad to the vendor TLV in DCBX.
>
> .John
I will send a V3 of this patchset without the ratelimit patch, to make
sure the patchset will get into net-next on time.
Thanks,
Amir
next prev parent reply other threads:[~2012-03-27 12:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-26 9:07 [PATCH V2 0/7] net/mlx4_en: DCB QoS support Amir Vadai
2012-03-26 9:07 ` [PATCH V2 1/7] net/mlx4_en: Force user priority by QP attribute Amir Vadai
2012-03-26 9:07 ` [PATCH V2 2/7] net/mlx4_core: set port QoS attributes Amir Vadai
2012-03-26 9:07 ` [PATCH V2 3/7] net/mlx4_en: DCB QoS support Amir Vadai
2012-03-26 9:07 ` [PATCH V2 4/7] net/mlx4_en: Set max rate-limit for a TC Amir Vadai
2012-03-26 14:46 ` Ben Hutchings
2012-03-26 17:00 ` Or Gerlitz
2012-03-26 18:55 ` John Fastabend
2012-03-27 12:03 ` Amir Vadai [this message]
2012-03-26 19:49 ` Roland Dreier
2012-03-26 9:07 ` [PATCH V2 5/7] net/mlx4_en: sk_prio <=> UP for untagged traffic Amir Vadai
2012-03-26 9:07 ` [PATCH V2 6/7] net/route: export symbol ip_tos2prio Amir Vadai
2012-03-26 9:07 ` [PATCH V2 7/7] IB/rdma_cm: TOS <=> UP mapping for IBoE Amir Vadai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F71ACAD.7010803@mellanox.com \
--to=amirv@mellanox.com \
--cc=amirv@dev.mellanox.co.il \
--cc=bhutchings@solarflare.com \
--cc=john.r.fastabend@intel.com \
--cc=liranl@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=or.gerlitz@gmail.com \
--cc=oren@mellanox.com \
--cc=yevgenyp@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.