netdev - Re: [RFC PATCH v1] iproute2: add IFLA

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: <1292419188.2067.27.camel@mojatatu>
Date:	Wed, 15 Dec 2010 08:19:48 -0500
From:	jamal <hadi@...erus.ca>
To:	John Fastabend <john.r.fastabend@...el.com>
Cc:	"shemminger@...tta.com" <shemminger@...tta.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"tgraf@...radead.org" <tgraf@...radead.org>,
	"eric.dumazet@...il.com" <eric.dumazet@...il.com>,
	"davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [RFC PATCH v1] iproute2: add IFLA_TC support to 'ip link'

Sorry for the latency.

On Thu, 2010-12-09 at 11:58 -0800, John Fastabend wrote:

> I think what we really want is a container to create groups of tx queues 
> which can then be managed and given a scheduler. One reason for this is 
> the 802.1Q spec allows for different schedulers to be running on different
> traffic classes including vendor specific schedulers. So having a root 
> "hardware-kinda-8021q-sched" doesn't seem flexible enough to handle 
> adding/removing schedulers per traffic class.
> 
> With a container qdisc statistics roll up nicely as expected and 
> the default scheduler can be the usual mq qdisc.

As far as i can see the "container" is a qdisc. The noun doesnt
matter, mq looks sufficient.
[I just said "hardware-kinda-8021q-sched" because what you posted didnt
look 8012q conformant.]
 
> A first take at this coming shortly. Any thoughts?

Havent had time to look at patches you posted.

> > Ok, so you can do rate control as well?
> 
> Yes, but per tx_ring. So software needs to then balance the rings into
> an aggregated rate limiter. Using the container scheme I imagine a root 
> mclass qdisc with multiple "sch_rate_limiter" qdiscs. This qdisc could 
> manage the individual rate limiters per queue and get something like a 
> rate limiter per groups of tx queues.
> 

The qdisc semantics allow for hierachies i.e you could have qdiscs that
hold other qdiscs that each hold different scheduling algorithms etc.

> Yes this is how I would expect this to work. The prio mapping is configurable
> so I think this could be worked around by policy in tc. iproute2 would need 
> to pick a reasonable default mapping.
> 
> Warning thinking out loud here but maybe we could also add a qdisc op to pick 
> the underlying tx queue basically a qdisc ops for dev_pick_tx(). This ops could 
> be part of the root qdisc and called in dev_queue_xmit(). I would need to think 
> about this some more to see if it is sane but bottom line is the tx queue needs 
> to be learned before __dev_xmit_skb(). The default mechanism in this patch set 
> being the skb prio.
> 

You could use the qdisc major:minor to map to the hardware level queues.
But care is needed so that the user doesnt choose the wrong mapping, out
of boundary mapping etc. I am sure such validation can be done at
iproute2 level way before the hardware is configured.

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