[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2722132.FiOmuVe0fZ@h2o.as.studentenwerk.mhn.de>
Date: Sat, 13 Dec 2014 01:43:05 +0100
From: Wolfgang Walter <linux@...m.de>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Thomas Jarosch <thomas.jarosch@...ra2net.com>,
netdev@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: [bisected] xfrm: TCP connection initiating PMTU discovery stalls on v3.
Am Freitag, 12. Dezember 2014, 16:15:40 schrieb Eric Dumazet:
> On Sat, 2014-12-13 at 00:47 +0100, Wolfgang Walter wrote:
> > I can't disable it as the driver will not allow it:
> > # ethtool -K eth0 tx off
> > Cannot change tx-checksumming
> > Could not change any device features
>
> Sounds a bug in itself :(
>
Yes, that is what I meant in my email that there seems also to be bug in the
GSO path.
I don't understand how tcp_sendmsg() marks gso/non-gso skbs.
tcp_send_mss() calls tcp_xmit_size_goal() which calls tcp_xmit_size_goal() and
there is a check for GSO ( sk_can_gso(sk) ). If sk_can_gso() returns false
then tcp_xmit_size_goal() returns mss_now. gso_segs seems to be set to zero.
In in tcp_output.c gso_segs == 0 seems to allow GSO.
What if mss later shrinks? Couldn't it be that then tcp_set_skb_tso_segs()
gets called and then there the gso branch is taken?
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
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