[gPXE] any negative implications of setting TCP window size to (65536 - 4) ?

[Stefan Hajnoczi]

On Tue, Feb 2, 2010 at 6:01 AM, Joshua Oreman <oremanj at rwcr.net> wrote:
> On Mon, Feb 1, 2010 at 11:50 PM, Marty Connor <mdc at etherboot.org> wrote:
>>> On the other hand, we're probably safe bumping it to 256kB. Thoughts
>>> from other developers?
>>
>> I think 256kB must be a typo because that's twice the heap size.  Did you
>> mean 16KB or 24KB
>
> Sorry, I meant increase the heap to 256kB. The TCP window size can't
> go over 64kB because the window space is represented in a 16-bit
> integer field.

Is an option to increase window size that could be looked into:

http://en.wikipedia.org/wiki/TCP_window_scale_option

Apparently Linux and Windows both use this option.

>> I have a suspicion (didn't look) that each connection is going to allocate
>> this amount of memory, so with a lot of connections, things could get ugly
>> real fast.  Put 3 NICs in a machine with those settings, and let's see what
>> happens when they all meed to do DHCP :)
>
> The memory is not allocated statically; it'll only come into play if
> all three connections actually have to buffer 64kB of data because
> they're receiving it so fast. Since gPXE generally only has one
> connection actively working at a time, I doubt this will be a big
> problem for us.

Related note: there is already a rule for choosing the receive window
size dynamically in net/tcp.c, but I guess it doesn't work well
because freemem is usually >4KB and we are therefore always limited by
the TCP_MAX_WINDOW_SIZE (4 KB):

/* Expand receive window if possible */
max_rcv_win = ( ( freemem * 3 ) / 4 );
if ( max_rcv_win > TCP_MAX_WINDOW_SIZE )
    max_rcv_win = TCP_MAX_WINDOW_SIZE;

The freemem variable is exported by the core/malloc.c to give the
amount of free space left on the heap.

Stefan