On Fri, Aug 22, 2008 at 10:12 PM, Herbert Xu
[off-list ref] wrote:

Alexander Duyck [off-list ref] wrote:

quoted

That issue led me to the thought of creating a redirect action that
would take the packet from one qdisc to the correct qdisc for the
transmit queue.  That setup has two issues.  First, all traffic would
need to go to one queue by default to avoid a possible deadlock
condition in the event that two queues try to enqueue packets on one
another at the same time.  That combined with the fact that one packet

That looks like a problem but it isn't.  When you're overriding
the default queue selection you're breaking CPU affinity.  As such
cache-line bouncing is clearly not a concern or you wouldn't be
doing this (that is, you're doing this for QOS rather than CPU
scalability).  So having everything go through a single qdisc
shouldn't be a problem.

Cheers,

It isn't the performance aspect of running everything through one
queue that I am concerned about since that is how it was working
before.  My concern is that the action could cause a dead lock if
simple_tx_hash places traffic on 2 queues and then the tc rule tried
to swap the traffic between those queues while they are each holding
their own queue locks.  The tc rule would have to receive all traffic
onto a single qdisc to prevent this, which would require setting
select_queue for the netdev to return a fixed queue.  The multiqueue
prio qdisc is flexible enough to allow all traffic to be directed to
one queue or be received on multiple queues without causing the system
to lock up which means that implementing select_queue on the device
wouldn't be mandatory.

Thanks,

Alex