lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1377686084.8828.175.camel@edumazet-glaptop>
Date:	Wed, 28 Aug 2013 03:34:44 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Jason Wang <jasowang@...hat.com>
Cc:	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Neal Cardwell <ncardwell@...gle.com>,
	Yuchung Cheng <ycheng@...gle.com>,
	Van Jacobson <vanj@...gle.com>,
	Tom Herbert <therbert@...gle.com>,
	"Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [PATCH v3 net-next] tcp: TSO packets automatic sizing

On Wed, 2013-08-28 at 15:37 +0800, Jason Wang wrote:

> > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> > index 884efff..e63ae4c 100644
> > --- a/net/ipv4/tcp_output.c
> > +++ b/net/ipv4/tcp_output.c
> > @@ -1631,7 +1631,7 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb)
> >  
> >  	/* If a full-sized TSO skb can be sent, do it. */
> >  	if (limit >= min_t(unsigned int, sk->sk_gso_max_size,
> > -			   sk->sk_gso_max_segs * tp->mss_cache))
> > +			   tp->xmit_size_goal_segs * tp->mss_cache))
> >  		goto send_now;
> A question is: Does this really guarantee the minimal TSO segments
> excluding the case of small available window? The skb->len may be much
> smaller and can still be sent here. Maybe we should check skb->len also?

tcp_tso_should_defer() is all about hoping the application will
'complete' the last skb in write queue with more payload in the near
future.

skb->len might therefore change because sendmsg()/sendpage() will add
new stuff in the skb.

We try hard to not remove tcp_tso_should_defer() and take the best of
it. We have not yet decided to add a real timer instead of relying on
upcoming ACKS.

Neal has an idea/patch to avoid a defer depending on
the expected time of following ACKS.

By making the TSO sizes smaller for low rates, we avoid these stalls
from tcp_tso_should_defer(), because an incoming ACK has normally freed
enough window to send the next packet in write queue without the need to
split it into two parts.

These changes are fundamental to use delay based congestion modules like
Vegas/Westwood and experimental new ones, without having to disable TSO.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ