[OpenAFS-devel] read performance 1.5.74 Linux

[Jeffrey Hutzelman]

--On Tuesday, May 18, 2010 09:39:01 AM -0400 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

> The reason that the lack of rx_TrimDataBufs() was hurting the kernel
> build of rx is that the kernel build has no mechanism to allocate
> packets while reading data from the network if the free packet queue is
> empty.  Therefore, there is logic in place that forces packets to be
> torn apart (reclaiming) whenever the free packet counts reach a low
> water mark.  The other size effect is that data that is being received
> is dropped on the floor.  This is necessary to prevent a panic.

I'm concerned here that this might mean you are lying about window sizes.

The reason some data buffers are allocated in advance is because you must 
be prepared to receive any data that can be in flight according to the 
advertised window size _without blocking_ or at least without blocking in a 
way that prevents traffic in another stream from being received and 
processed.  Tearing apart other packets to reclaim buffers is acceptable, 
but not if it means you need to wait for a buffer to drain before you can 
receive more packets.  Dropping received data on the floor when it was 
received within the advertised window is _not_ acceptable; that breaks flow 
control and exacerbates congestion.

-- Jeff