netdev - Re: [RFC PATCH] net: add a rate_limit attribute to netdev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51DE220A.40505@intel.com>
Date:	Wed, 10 Jul 2013 20:10:02 -0700
From:	John Fastabend <john.r.fastabend@...el.com>
To:	Tom Herbert <therbert@...gle.com>
CC:	John Fastabend <john.fastabend@...il.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	ben@...adent.org.uk,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [RFC PATCH] net: add a rate_limit attribute to netdev_queue and
 a rtnetlink

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html