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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
