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
|