On Tue, 09 Oct 2007 13:43:31 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
> From: Andi Kleen <[EMAIL PROTECTED]> > Date: 09 Oct 2007 18:51:51 +0200 > > > 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. > > Indeed, I also realized last night that for the default qdiscs > we do a lot of stupid useless work. If the queue is a FIFO > and the device can take packets, we should send it directly > and not stick it into the qdisc at all. > > > 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) > > Absolutely. > > Our packet scheduler subsystem is great, but by default it should just > get out of the way. I was thinking why not have a default transmit queue len of 0 like the virtual devices. -- Stephen Hemminger <[EMAIL PROTECTED]> - 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
