On Tue, Feb 2, 2010 at 6:01 AM, Joshua Oreman <[email protected]> wrote: > On Mon, Feb 1, 2010 at 11:50 PM, Marty Connor <[email protected]> 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 _______________________________________________ gPXE mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe
