Re: [RFC PATCH] net: add a rate_limit attribute to netdev_queue and a rtnetlink

[John Fastabend <john.r.fastabend@intel.com>]

On 7/10/2013 2:18 PM, Tom Herbert wrote:
> John, thanks for posting this.
>
> Should we have separate guaranteed and maximum rate?  Will this be
> usable in the case that more than one queue shares a rate?  Do you
> think other parameters, like priority weights should be done the same
> way?
>
> Tom
>

If hardware can provide a guaranteed min rate as well as a max rate
per queue then I think adding it here would be correct. Notice
guaranteed minimum rates and max rates can already be provided for a
set of queues (a traffic class or tc in the netdev struct) using the
DCB netlink interface.

So we have a hierarchy of attributes namely netdev->tc->queue.
It might be interesting to note a tc can consist of a single queue.
However hardware may not necessarily be able to rate limit a set of
queues or vice versa a single queue.

> 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?

> Do you think other parameters, [...]

With regards to other attributes my intent was to create a structure
that we could easily add additional per queue attributes as needed.
So yes adding priority weights here makes some sense to me. Although
I wonder if priority weights overlaps the 'queue set' and 'tc' notion
already existing in the DCB netlink interface for configuring link
strict classes. With dcbnl and mqprio we can create upto 16 sets
of queues each with a priority mapping and the hardware will process
traffic in priority order. (ixgbe caveat: 82599 supports 8 sets of
queues X540 supports 4).

.John