--On Tuesday, May 18, 2010 09:39:01 AM -0400 Jeffrey Altman
<[email protected]> 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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
