David Miller <davem@davemloft.net> writes:
quoted text
> 
> 2) Switch the default qdisc away from pfifo_fast to a new DRR fifo
>    with load balancing using the code in #1.  I think this is kind
>    of in the territory of what Peter said he is working on.

Hopefully that new qdisc will just use the TX rings of the hardware
directly. They are typically large enough these days. That might avoid
some locking in this critical path.

quoted text
>    I know this is controversial, but realistically I doubt users
>    benefit at all from the prioritization that pfifo provides.

I agree. For most interfaces the priority is probably dubious.
Even for DSL the prioritization will be likely usually done in a router
these days.

Also for the fast interfaces where we do TSO priority doesn't work
very well anyways -- with large packets there is not too much 
to prioritize.

quoted text
> 3) Work on discovering a way to make the locking on transmit as
>    localized to the current thread of execution as possible.  Things
>    like RCU and statistic replication, techniques we use widely
>    elsewhere in the stack, begin to come to mind.

If the data is just passed on to the hardware queue, why is any 
locking needed at all? (except for the driver locking of course)

-Andi
-
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