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: <CA+mtBx-FyprEihCsvirrTAQZsPi_1P+YAfqxkSC+B1ho-KyfiQ@mail.gmail.com>
Date:	Sun, 14 Jul 2013 14:14:14 -0700
From:	Tom Herbert <therbert@...gle.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	John Fastabend <john.r.fastabend@...el.com>,
	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>
Subject: Re: [RFC PATCH] net: add a rate_limit attribute to netdev_queue and a rtnetlink

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

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