On Tue, May 18, 2010 at 11:16 AM, Jeffrey Hutzelman <[email protected]> wrote: > --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.
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. -- Derrick _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
