[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <470AD9DD.2080707@garzik.org>
Date: Mon, 08 Oct 2007 21:31:09 -0400
From: Jeff Garzik <jeff@...zik.org>
To: hadi@...erus.ca
CC: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
David Miller <davem@...emloft.net>, krkumar2@...ibm.com,
johnpol@....mipt.ru, herbert@...dor.apana.org.au, kaber@...sh.net,
shemminger@...ux-foundation.org, jagana@...ibm.com,
Robert.Olsson@...a.slu.se, rick.jones2@...com, xma@...ibm.com,
gaagaan@...il.com, netdev@...r.kernel.org, rdreier@...co.com,
mcarlson@...adcom.com, mchan@...adcom.com,
general@...ts.openfabrics.org, tgraf@...g.ch,
randy.dunlap@...cle.com, sri@...ibm.com
Subject: Re: [PATCH 2/3][NET_BATCH] net core use batching
jamal wrote:
> The challenge to deal with is that netdevices, filters, the queues and
> scheduler are closely inter-twined. So it is not just the scheduling
> region and QDISC_RUNNING. For example, lets pick just the filters
> because they are simple to see: You need to attach them to something -
> whatever that is, you then need to synchronize against config and
> multiple cpus trying to use them. You could:
> a) replicate them across cpus and only lock on config, but you are
> wasting RAM then
I think you've pretty much bought into the cost of wasting RAM, when
doing multiple TX rings. So logic implies associated costs, like the
ones you describe, come along for the ride.
> b) attach them to rings instead of netdevices - but that makes me wonder
> if those subqueues are now going to become netdevices. This also means
> you change all user space interfaces to know about subqueues. If you
> recall this was a major contention in our earlier discussion.
That's definitely a good question, and I honestly don't see any easy
solutions.
Multiple net devices makes a -lot- of things easier, with regards to
existing infrastructure, but it also imposes potentially annoying
administrative burdens: Not only must each interface be set up
individually, but the userland apps must be made aware of this unique
method of concurrency.
Jeff
-
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
Powered by blists - more mailing lists