Rodney W. Grimes wrote:
[stuff snipped]
> I wrote:
>> Btw, NFS often causes this because...
>> - Typically TSO is limited to a 64K packet (including TCP/IP and MAC 
>> headers).
>> - When NFS does reading/writing, it will do 64K + NFS, TCP/IP and MAC headers
>>   for an RPC (or a multiple of 64K like 128K).
>> --> This results in tcp_output() generating a 64K TSO segment followed by a
>>      small TCP segment (since another RPC message doesn;t usually end up
>>      queued quickly enough to fill in the rest of the second TCP segment).
>> - Also, at the end of file, you can get an RPC which is just under 64K 
>> including
>>   NFS and TCP/IP headers. (The drivers often broke when adding the MAC
>>   header bumped this case to > 64K.)
>> Thanks go to Yuri for diagnosing this, rick
> Just a thought, not asking anyone to write one :-)
> It would be handy to have some sh(1) scripts that can exercise this bug
> case and have it readily avaliable to network driver authors for testing
> the tso (or other large segment) code.
You can't easily reproduce this from userland. It depends on the way NFS fills 
the mbuf chain for I/O RPCs. (iSCSI does something similar.)

However, if your shell script does an NFS mount and the writes/reads a
file just under 64K in size on the mount...

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to