All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Markus Trippelsdorf <markus@trippelsdorf.de>, netdev@vger.kernel.org
Subject: Re: "TCP: eth0: Driver has suspect GRO implementation, TCP performance may be compromised." message with "ethtool -K eth0 gro off"
Date: Fri, 3 Feb 2017 11:53:55 -0200	[thread overview]
Message-ID: <20170203135355.GA3413@localhost.localdomain> (raw)
In-Reply-To: <1486128246.21871.83.camel@edumazet-glaptop3.roam.corp.google.com>

On Fri, Feb 03, 2017 at 05:24:06AM -0800, Eric Dumazet wrote:
> On Fri, 2017-02-03 at 09:54 -0200, Marcelo Ricardo Leitner wrote:
> > On Thu, Feb 02, 2017 at 05:59:24AM -0800, Eric Dumazet wrote:
> > > On Thu, 2017-02-02 at 05:31 -0800, Eric Dumazet wrote:
> > > 
> > > > Anyway, I suspect the test is simply buggy ;)
> > > > 
> > > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> > > > index 41dcbd568cbe2403f2a9e659669afe462a42e228..5394a39fcce964a7fe7075b1531a8a1e05550a54 100644
> > > > --- a/net/ipv4/tcp_input.c
> > > > +++ b/net/ipv4/tcp_input.c
> > > > @@ -164,7 +164,7 @@ static void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb)
> > > >  	if (len >= icsk->icsk_ack.rcv_mss) {
> > > >  		icsk->icsk_ack.rcv_mss = min_t(unsigned int, len,
> > > >  					       tcp_sk(sk)->advmss);
> > > > -		if (unlikely(icsk->icsk_ack.rcv_mss != len))
> > > > +		if (unlikely(icsk->icsk_ack.rcv_mss != len && skb_is_gso(skb)))
> > > >  			tcp_gro_dev_warn(sk, skb);
> > > >  	} else {
> > > >  		/* Otherwise, we make more careful check taking into account,
> > > 
> > > This wont really help.
> > > 
> > > Our tcp_sk(sk)->advmss can be lower than the MSS used by the remote
> > > peer.
> > > 
> > > ip ro add .... advmss 512
> > 
> > I don't follow. With a good driver, how can advmss be smaller than the
> > MSS used by the remote peer? Even with the route entry above, I get
> > segments just up to advmss, and no warning.
> > 
> 
> A TCP flow has two ends.

Indeed, though should be mostly about only one of them.

> 
> Common MTU = 1500
> 
> One can have advmss 500, the other one no advmss (or the standard 1460
> one)

Considering the rx side of peer A. Peer A advertises a given MSS to peer
B and should not receive any segment from peer B larger than so.
I'm failing to see how advmss can be smaller than the segment size just
received.

> 
> So if we compare apple and orange, result might be shocking ;)

Yes heh just not seeing the mix here..

> 
> If you want to reproduce this use the "ip ro add .... advmss 512" hint,
> and/or play with sysctl_tcp_mtu_probing

I tried the route with advmss, no luck so far.
Still digging..

  Marcelo

  reply	other threads:[~2017-02-03 13:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-02 11:52 "TCP: eth0: Driver has suspect GRO implementation, TCP performance may be compromised." message with "ethtool -K eth0 gro off" Markus Trippelsdorf
2017-02-02 12:32 ` Eric Dumazet
2017-02-02 12:34   ` Markus Trippelsdorf
2017-02-02 13:31     ` Eric Dumazet
2017-02-02 13:59       ` Eric Dumazet
2017-02-03 11:54         ` Marcelo Ricardo Leitner
2017-02-03 12:06           ` Markus Trippelsdorf
2017-02-03 13:24           ` Eric Dumazet
2017-02-03 13:53             ` Marcelo Ricardo Leitner [this message]
2017-02-03 14:16               ` Eric Dumazet
2017-02-03 14:28                 ` Marcelo Ricardo Leitner
2017-02-03 14:47                   ` Eric Dumazet
2017-02-06 21:12                     ` Marcelo Ricardo Leitner
2017-03-10 12:22                       ` Markus Trippelsdorf
2017-03-19 12:14                       ` Markus Trippelsdorf
2017-03-19 19:20                         ` Eric Dumazet
2017-03-20 19:27                           ` Marcelo Ricardo Leitner
2017-03-22 13:47                             ` Eric Dumazet
2017-03-24 15:56                               ` Marcelo Ricardo Leitner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170203135355.GA3413@localhost.localdomain \
    --to=marcelo.leitner@gmail.com \
    --cc=eric.dumazet@gmail.com \
    --cc=markus@trippelsdorf.de \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.