netdev
[Top] [All Lists]

Re: Queue and SMP locking discussion (was Re: 3c59x.c)

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: Queue and SMP locking discussion (was Re: 3c59x.c)
From: Donald Becker <becker@xxxxxxxxx>
Date: Fri, 31 Mar 2000 11:16:56 -0500 (EST)
Cc: Andrew Morton <andrewm@xxxxxxxxxx>, netdev@xxxxxxxxxxx, kuznet@xxxxxxxxxxxxx
In-reply-to: <Pine.GSO.4.20.0003310847310.16592-100000@shell.cyberus.ca>
Sender: owner-netdev@xxxxxxxxxxx
On Fri, 31 Mar 2000, jamal wrote:
> On Fri, 31 Mar 2000, Andrew Morton wrote:
> 
> > I believe that this tx starvation is due to the decision to schedule the
> > tx in the device ISR, for BH handling, rather than to actually dequeue
> > and send packets within the Tx ISR.  I can see why the bh scheduling is
> > simpler...
> > 
> > I like the loop-until-max_interrupt_work-exceeded architecture.  It's
> > _very_ efficient compared with interrupt per packet, and it kicks in
> > when the system is under stress.  But it's not being leveraged for
> > transmits.
>
> loop-until-max_interrupt_work-exceeded will *not* help you in this.

It does limit the work done by a specific subsystem so that other devices on
the same IRQ chain can do their work.  At the end of the handler scan the
interrupt dispatch system a chance to run other IRQ chains.

> Packet arrivals still mean interupts.

Most machines could never see a regime where they are overwhelmed by just
accepting incoming packets.  In the situation where it occurs, usually only
gigabit cards or multiple 100baseTx connections, there must be
discard/ignore policy.  You must drop packets on the floor, and it's
arguably best to not be transmitting while the discard is occurring.  Given
that this is a box-stopping load, I don't see transmit starvation as even an
issue, let alone a problem.  Transmit starvation is arguably the best
behavior.

If you must deploy a machine in these conditions, use newer hardware that
implements hardware-triggered flow control.  Even the $12 RTL8139B cards
implement it.

> Mitigation (which seems to be added to some of Donalds drivers by Jeff
> Garzik and Andrey Savochkin) will to a certain extent.

Huh?  I've used software interrupt mitigation all along, and typically used
the hardware interrupt mitigation where it existed.  I don't see that
any new driver structure has been added by Garzik or Savochkin.

Adding non-hardware interrupt mitigation to the receive routine is a bad
idea.  You could easily end up with a single packet sitting in Rx queue for
ages.

Donald Becker
Scyld Computing Corporation, becker@xxxxxxxxx


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