Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.

From: Linas Vepstas
Date: Fri Aug 18 2006 - 18:43:52 EST

On Fri, Aug 18, 2006 at 02:25:13PM -0700, David Miller wrote:
> From: linas@xxxxxxxxxxxxxx (Linas Vepstas)
> Date: Fri, 18 Aug 2006 14:23:56 -0500
> > On Thu, Aug 17, 2006 at 01:43:40AM +0200, Benjamin Herrenschmidt wrote:
> > >
> > > Sounds good (without actually looking at the code though :), that was a
> > > long required improvement to that driver. Also, we should probably look
> > > into using NAPI polling for tx completion queue as well, no ?
> >
> > Just for a lark, I tried using NAPI polling, while disabling all TX
> > interrupts. Performance was a disaster: 8Mbits/sec, fom which I conclude
> > that the tcp ack packets do not flow back fast enough to allw reliance
> > on NAPI polling for transmit.
> The idea is to use NAPI polling with TX interrupts disabled.

The idea of a low-watermark mark interrupt is that there are *zero*
interrupts, as long as the kernel keeps feeding packets to the device.

In my last email to you, I attached a real-life vmstat trace
showing exactly zero interrupts over a two minute period.

However, the zero-interrupt scenario only occurs if the kernel
is actually feeding packets to the driver. If the socket beffers
are small, then the app blocks, the kernel is idle, and there
are not enough tcp ack packets coming back the other way to
actually get the NAPI polling to keep the adapter fed.

> We're not saying to use the RX interrupt as the trigger for
> RX and TX work. Rather, either of RX or TX interrupt will
> schedule the NAPI poll.

And, for a lark, this is exactly what I did. Just to see.
Because there are so few ack packets, there are very few
RX interrupts -- not enough to get NAPI to actually keep
the device busy.

I'm somewhat disoriened from this conversation. Its presumably
clear that low-watermark mechanisms are superior to NAPI.
>From what I gather, NAPI was invented to deal with cheap
or low-function hardware; it adds nothing to this particular
situation. Why are we talking about this?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at