On 09 Oct 2007 18:51:51 +0200
Andi Kleen <andi@firstfloor.org> wrote:

quoted text
> David Miller <davem@davemloft.net> writes:
> > 
> > 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.
> 
> >    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.
> 
> > 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

I wonder about the whole idea of queueing in general at such high speeds.
Given the normal bi-modal distribution of packets, and the predominance
of 1500 byte MTU; does it make sense to even have any queueing in software
at all?


-- 
Stephen Hemminger <shemminger@linux-foundation.org>
-
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