netdev - Re: [PATCH net-next 1/2] net: ethernet: cortina: Restore TSO support

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]

Date: Thu, 9 May 2024 19:42:33 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Hans Ulli Kroll <ulli.kroll@...glemail.com>, "David S. Miller" <davem@...emloft.net>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/2] net: ethernet: cortina: Restore TSO support

On Thu, May 9, 2024 at 4:49 PM Eric Dumazet <edumazet@...gle.com> wrote:
> On Thu, May 9, 2024 at 4:38 PM Linus Walleij <linus.walleij@...aro.org> wrote:


> > tcpdump -e -X enp2s0 gives this on a single segment in a segmented
> > iperf3 -c transfer:
> >
> > 16:24:09.182095 14:d6:4d:a8:3c:4f (oui Unknown) > fc:34:97:01:a0:c6
> > (oui Unknown), ethertype IPv4 (0x0800), length 1448: OpenWrt.lan.56624

Notice ^^^ "length 1448, that's at the link layer.

> > > Fecusia.targus-getdata1: Flags [.], seq 18664:20046, ack 1, win
> > 4198, options [nop,nop,TS val 2770370491 ecr 3490176978], length 1382

That is on ... whatever tcpdump decide to show.

OK I might not be the best with this tool.

> >     0x0000:  4500 059a 8ff6 4000 4006 218d c0a8 0188  E.....@.@.......
> >     0x0010:  c0a8 0102 dd30 1451 a701 4f9d e809 8788  .....0.Q..O.....
> >     0x0020:  8010 1066 0b60 0000 0101 080a a520 7fbb  ...f.`..........

Ethernet headers missing here.

> > (...)
> >     0x0580:  de60 2081 5678 4f8b 31b1 6f85 87fe ae63  .`..VxO.1.o....c
> >     0x0590:  e2ca 8281 fa72 16aa 52e2                 .....r..R.
> >
> > As can be seen in the header, it is indeed 1448 bytes when arriving
> > as well, so it seems to work!
>
> Not really.
>
> Try to disable TSO, and look at the resulting incoming packets, how
> they are different.
>
> If skb_shinfo(skb)->gso_size is 1448, you should receive something like
>
> seq 18664:20112 .... length 1448  (this is the payload len at this stage)

I think that is what I get?

> If you receive instead ".... length 1382" this means you gave to the
> NIC a 'link layer MSS' too small by 66 bytes.

I think it's right, I just suck at using tcpdump switches :/

Yours,
Linus Walleij