[Top] [All Lists]

Re: [RFC] netif_rx: receive path optimization

To: netdev <netdev@xxxxxxxxxxx>
Subject: Re: [RFC] netif_rx: receive path optimization
From: Rick Jones <rick.jones2@xxxxxx>
Date: Thu, 31 Mar 2005 16:42:11 -0800
In-reply-to: <>
References: <> <> <1112303431.1073.67.camel@jzny.localdomain> <> <1112305084.1073.94.camel@jzny.localdomain> <> <> <> <>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304
Well, I'm in an email discussion with someone who seems to bump their TCP windows quite large, and disable timestamps...

And do they like the resulting data corruption.

Minor nit - potential data corruption, perhaps even probable, but I don't think they are all that concerned yet - feeling secure in their belief that 2*MSL on a LAN is rather short indeed, and perhaps even in WANs where using 1GB TCP windows (although I may have mixed too much together there).

Of course, if we believe that stacks should be smart enough to limit the initial receive windows (or does a setsockopt() actrually override that?), and grow them over time based on what the transfer rates might be and the like, perhaps the stack should have a hard interlock on TCP window >= 65535 and timestamp option on. No timestamps, no window > 65535 bytes. At present, it seems possible to have one without the other. Of course, if one is indeed on a "LAN" and _knows_ (somehow, given the existence of remote bridges) that it is a LAN.

rick jones

<Prev in Thread] Current Thread [Next in Thread>