On Nov 6, 2015, at 4:16 PM, Hans Petter Selasky <h...@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


_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to