[OpenAFS-devel] read performance 1.5.74 Linux

[Derrick Brashear]

On Tue, May 18, 2010 at 11:16 AM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
> --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. =A0Therefore, there is logic in place that forces packets to be
>> torn apart (reclaiming) whenever the free packet counts reach a low
>> water mark. =A0The other size effect is that data that is being received
>> is dropped on the floor. =A0This 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. =A0Tearing apart other packets to reclaim buffers is acceptabl=
e,
> but not if it means you need to wait for a buffer to drain before you can
> receive more packets. =A0Dropping received data on the floor when it was
> received within the advertised window is _not_ acceptable; that breaks fl=
ow
> control and exacerbates congestion.

If we were lying, we were before, rather than now. He's describing how
things did already work, not how they do now. So, perhaps, but, not a
new problem.





--=20
Derrick