Date: Fri, 6 Nov 2015 21:56:43 +0000 From: "Cui, Cheng" <Cheng.Cui@netapp.com> To: Hans Petter Selasky <hps@selasky.org> Cc: "Cui, Cheng" <Cheng.Cui@netapp.com>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: question about trimning data "len" conditions in TSO in tcp_output.c Message-ID: <E6DBCD15-A41C-49A4-88C5-FB79EC969716@netapp.com> In-Reply-To: <563D1892.3050406@selasky.org> References: <C44A2900-40E0-41EF-83B1-6DD4B31DABD5@netapp.com> <563D1892.3050406@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 6, 2015, at 4:16 PM, Hans Petter Selasky <hps@selasky.org> wrote: > On 11/06/15 21:46, Cui, Cheng wrote: >> Hello Hans, >> >> Sorry if my previous email does not reach you because of a bad subject. >> >> This is Cheng Cui. I am reading the CURRENT FreeBSD code in tcp_output.c, and find this question regarding your change in revision 271946. >> https://svnweb.freebsd.org/base/head/sys/netinet/tcp_output.c?r1=271946&r2=271945&pathrev=271946 >> >> trim data "len" under TSO: >> >> 885 /* >> 886 * Prevent the last segment from being >> 887 * fractional unless the send sockbuf can be >> 888 * emptied: >> 889 */ >> 890 max_len = (tp->t_maxopd - optlen); >> 891 if ((off + len) < sbavail(&so->so_snd)) { <== >> 892 moff = len % max_len; >> 893 if (moff != 0) { >> 894 len -= moff; >> 895 sendalot = 1; >> 896 } >> 897 } >> >> Is there a specific reason that it should skip trimming the data "len" under the condition of "(off + len) == sbavail(&so->so_snd)" in TSO? > > Because I am wondering if we can trim the data "len" directly without checking the "(off + len)" condition. > > Hi Cheng, > > I believe the reason is to avoid looping one more time outputting a single packet containing the remainder of the available data, with regard to max_len. How did you envision the removal of this check would influence the generated packet sequence? > > --HPS > Hi Hans, I may be wrong but my assumption is that the remainder of the available data may be larger than one single packet. Suppose max_len==1500, sb_acc==3001, off==2, and (off+len)==3001. In this case, the current code will not trim the "len" and let it go directly to the NIC. I think it skips the Nagle's algorithm. As len==2999, the last packet is 1499, it is supposed to be held until all outstanding data are ACKed, but it has been sent out. Cheng
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E6DBCD15-A41C-49A4-88C5-FB79EC969716>