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] [day] [month] [year] [list]

Message-ID: <51E36641.5090407@gmail.com>
Date:	Sun, 14 Jul 2013 20:02:25 -0700
From:	John Fastabend <john.fastabend@...il.com>
To:	Tom Herbert <therbert@...gle.com>,
	Jamal Hadi Salim <jhs@...atatu.com>
CC:	John Fastabend <john.r.fastabend@...el.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>
Subject: Re: [RFC PATCH] net: add a rate_limit attribute to netdev_queue and
 a rtnetlink

On 07/14/2013 02:14 PM, Tom Herbert wrote:
>> 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.
>>

Interesting. Just so I am clear on the example, with tc this would look
like classifying packets on egress and sending them to an IFB device and
similarly matching packets on ingress and sending them to the same IFB
device. Then applying a rate limit on the IFB?

The ingress AND egress part I hadn't considered. If its just ingress
(exclusive) OR egress then its basically a 802.1Q traffic class which
in my case and I assume for most hardware is just a set of queues.

> RIght, conceptually we want rate limit users or applications as
> opposed to queues.  For instance, for instance we may want to allocate
> four queues to a particular user for scaling, but rate limit user to
> 1Gbps in aggregate.  Assigning each queue 250Mbps is not the same!
> The generalization of this is to define QoS class describing rate
> limits and other properties, and allowing queues to be mapped to the
> these classes.
>
> Tom
>

How would this be different from the DCB netlink interface that already
exists? Is the piece I am missing to have a global rate for both egress
and ingress?

Today a traffic class is given a queue set via the mqprio interface
and then max rate for a traffic class can be configured via
DCB_ATTR_IEEE_MAXRATE. Then netprio_cgroup is used to map PIDs to the
traffic classes. So not exactly per user rates but per application.

.John

-- 
John Fastabend         Intel Corporation
--
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