jamal wrote:
quoted text
> 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.


quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html