[Top] [All Lists]

Re: Tx queueing

To: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Subject: Re: Tx queueing
From: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Sat, 20 May 2000 10:17:09 +1000
Cc: "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
References: <392407D4.BE586507@xxxxxxxxxx> <3925BA01.CC49AC1@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Jeff Garzik wrote:
> Andrew Morton wrote:
> >
> > A number of drivers do this:
> >
> > start_xmit()
> > {
> >         netif_stop_queue()
> >         ...
> >         if (room for another packet)
> >                 netif_wake_queue()
> >         ...
> > }
> Which ones?  They need fixing..

3c50?.c.  Probably others...

I'm disinclined to change these:

- They're slow anyway.
- Increased possiblity of breaking them
- Broken 2.2/kcompat24 compatibility

> > For devices which have a Tx packet ring or decent FIFO I don't expect
> > this to be a problem, because the Tx ISR will call netif_wake_queue()
> > and the subsequent BH run will keep stuffing packets into the Tx ring
> > until it's full.  But for devices which have very limited Tx buffering
> > there may be a lost opportunity to refill the Tx buffer earlier.  Seems
> > unlikely to me.
> If you do something like that, it seems like it should be dependent on
> certain thresholds, not necessarily occurring all the time.  And you'd
> want to sync with the Tx reaper called from the interrupt handler, too.

I guess if you need more performance out of most of the Linux net
drivers, you get it with a chequebook.  That leaves us only really
caring about performance on a handful of drivers, which is good.


- No performance tweaks for [E]ISA drivers in 2.3.  
- Correctness fixes if they're obvious.
- If the SMP-safety fixes are not obvious, mark the driver as UP-only.

Sound sensible?


<Prev in Thread] Current Thread [Next in Thread>