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 in 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... rick _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
