Re: [PATCH] atm: br2684: Fix excessive queue bloat

On Sun, Nov 25, 2012 at 10:01:32PM +0000, David Woodhouse wrote:

Yeah. This is fairly much the same conversation I ended up having when I
did the same for PPPoATM.

Some day *perhaps* we might look at doing something adaptive, so it'll
detect a TX underrun and increase the amount of buffering. But this
seems perfectly good for now.

The biggest problem is the existence of additional, mostly unnecessary
huge software queue that we have between us and the hardware on "ATM sockets".
Most of ATM drivers have some hardware queue, but accept and queue
additional frames in software and it just adds unnecessary delay
- it's much better to queue those frames in netdev queue. With this patch
we limit this queue by limiting the number of frames in this queue and
hardware queue to 2 frames, but the hardware may require larger *hardware*
queue to saturate the link. If we had only the hardware queue, the queue
would be probably sized adequately in ATM driver or could be tuned by user.

I think that the 2 frame queue is much better than the huge queue,
that we have now.

quoted

Maybe this magic "2" and the comment should be moved to some #define.

Doesn't make it any less magic. I'm happier with it as it is, with a
clear comment describing why it's done that way.

In PPPoATM we have NONE_INFLIGHT.

Krzysiek