On 5/18/2010 11:16 AM, Jeffrey Hutzelman wrote:
> I'm concerned here that this might mean you are lying about window sizes.

I (personally) am not lying about anything.  I really wish that *you*
could make a distinction between *me* and the open source code when
making comments.  The fact that I was the last person to touch the
source code does not make me personally responsible for all of its
warts.  The Rx implementation is the product of 20+ years of various
developers making modifications to it.  I am not the source code and I
take serious offense when *you* indicate that broken behavior in the
code that I am fixing is something that *I* am doing wrong.

> 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.

A packet is made up of multiple data buffers which are themselves
packets.  The window size in Rx is not measured in bytes.  It is
measured in packets and we have no idea how large the incoming packet
might be.  It can be as large as RX_MAX_PACKET_SIZE.  As such, before
any receive operation is performed the library must ensure that the full
number of data buffers has been attached to the packet.

> 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.

It is acceptable but it is also extremely inefficient because most
packets are not jumbo packets and as such only require a single data
buffer beyond the buffer used for the header.

>  Dropping received data on
> the floor when it was received within the advertised window is _not_
> acceptable; that breaks flow control and exacerbates congestion.

Of course it is but I believe that the early developers made a wise
choice being causing a kernel panic and being inefficient on the wire.
If you have to choose one, drop the data on the floor and let it be
retransmitted.

The goal is to ensure that we never get into this case which is why if
the rxi_NeedMorePackets global variable is TRUE we must actually go and
allocate more packets the next time it is safe to do so.

The patch that was committed today does that for the first time in the
history of Rx.

Jeffrey Altman

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to