From: Jamal Hadi Salim <jhs@mojatatu•com>
To: John Fastabend <john.r.fastabend@intel•com>
Cc: Tom Herbert <therbert@google•com>,
John Fastabend <john.fastabend@gmail•com>,
Stephen Hemminger <stephen@networkplumber•org>,
ben@decadent•org.uk, "Brandeburg,
Jesse" <jesse.brandeburg@intel•com>,
Linux Netdev List <netdev@vger•kernel.org>,
Jeff Kirsher <jeffrey.t.kirsher@intel•com>
Subject: Re: [RFC PATCH] net: add a rate_limit attribute to netdev_queue and a rtnetlink
Date: Sun, 14 Jul 2013 13:44:12 -0400 [thread overview]
Message-ID: <51E2E36C.8030307@mojatatu.com> (raw)
In-Reply-To: <51DE220A.40505@intel.com>
On 13-07-10 11:10 PM, John Fastabend wrote:
>
>> Will this be usable in the case that more than one queue shares a rate?
>
> Here I must not understand the question. Each queue has independent
> rate limiters. At least in the hardware supported by ixgbe. Maybe
> other hardware has a different implementation?
>
I think Tom might be alluding to scenarios where a rate (as a resource)
is shared by multiple ingress as well as egress interfaces (in your case
queues). This is a very popular use case with tc (in particular in
conjunction with IFB).
In such a case, the rate by itself would need to modeled as an indexable
attribute.
Some hardware (example modern broadcom switching chips, maybe yours)
are not capable; So the index would have local semantics as in your
case. But I know hardware that does support shared rates.
Maybe you could come up with IFLA_QUEUE_RATE_LOCAL vs
IFLA_QUEUE_RATE_GLOBAL which will encapsulate a global index
for the shared rate.
cheers,
jamal
next prev parent reply other threads:[~2013-07-14 17:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-10 14:04 [RFC PATCH] net: add a rate_limit attribute to netdev_queue and a rtnetlink John Fastabend
2013-07-10 21:18 ` Tom Herbert
2013-07-11 3:10 ` John Fastabend
2013-07-14 17:44 ` Jamal Hadi Salim [this message]
2013-07-14 21:14 ` Tom Herbert
2013-07-15 3:02 ` John Fastabend
2013-07-11 23:35 ` David Miller
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=51E2E36C.8030307@mojatatu.com \
--to=jhs@mojatatu$(echo .)com \
--cc=ben@decadent$(echo .)org.uk \
--cc=jeffrey.t.kirsher@intel$(echo .)com \
--cc=jesse.brandeburg@intel$(echo .)com \
--cc=john.fastabend@gmail$(echo .)com \
--cc=john.r.fastabend@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=stephen@networkplumber$(echo .)org \
--cc=therbert@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox