From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: alexandre.sidorenko@hpe.com, netdev@vger.kernel.org,
jmaxwell37@gmail.com, eric.dumazet@gmail.com
Subject: Re: Receive offloads, small RCVBUF and zero TCP window
Date: Mon, 28 Nov 2016 20:01:46 -0200 [thread overview]
Message-ID: <20161128220146.GA13169@localhost.localdomain> (raw)
In-Reply-To: <20161128.155459.1527519991492144879.davem@davemloft.net>
On Mon, Nov 28, 2016 at 03:54:59PM -0500, David Miller wrote:
> From: Alex Sidorenko <alexandre.sidorenko@hpe.com>
> Date: Mon, 28 Nov 2016 15:49:26 -0500
>
> > Now the question is whether is is OK to have icsk->icsk_ack.rcv_mss
> > larger than MTU.
>
> It absolutely is not OK.
>
Would it make sense to add a pr_warn_once() and perhaps even clamp it
down to known/saner MSS?
> If VMWare wants to receive large frames for batching purposes it must
> use GRO or similar to achieve that, not just send vanilla frames into
> the stack which are larger than the device MTU.
>
It's not the first report I've seen on this type of issue. IBM also had
this issue recently while not being able to send the gso_size from tx
side to rx, and the warning probably could have saved quite some
debugging time.
Something like (but with a better msg, for sure):
--8<--
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index a27b9c0e27c0..3a59cffae3fa 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -144,7 +144,9 @@ static void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb)
*/
len = skb_shinfo(skb)->gso_size ? : skb->len;
if (len >= icsk->icsk_ack.rcv_mss) {
- icsk->icsk_ack.rcv_mss = len;
+ icsk->icsk_ack.rcv_mss = max(len, tcp_sk(sk)->advmss);
+ if (icsk->icsk_ack.rcv_mss != len)
+ pr_warn_once("Your driver is likely doing bad rx acceleration.\n");
} else {
/* Otherwise, we make more careful check taking into account,
* that SACKs block is variable.
prev parent reply other threads:[~2016-11-28 22:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-28 20:49 Receive offloads, small RCVBUF and zero TCP window Alex Sidorenko
2016-11-28 20:54 ` David Miller
2016-11-28 21:14 ` Alex Sidorenko
2016-11-30 15:10 ` Alex Sidorenko
2016-11-28 22:01 ` Marcelo Ricardo Leitner [this message]
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=20161128220146.GA13169@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=alexandre.sidorenko@hpe.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jmaxwell37@gmail.com \
--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.