[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240820153840.GA977997@pevik>
Date: Tue, 20 Aug 2024 17:38:40 +0200
From: Petr Vorel <pvorel@...e.cz>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Xin Long <lucien.xin@...il.com>, netdev@...r.kernel.org
Subject: Re: [RFC] Big TCP and ping support vs. max ICMP{,v6} packet size
Hi Eric,
> On Mon, Aug 19, 2024 at 2:50 PM Petr Vorel <pvorel@...e.cz> wrote:
> > Hi Eric, Xin,
> > I see you both worked on Big TCP support for IPv4/IPv6. I wonder if anybody was
> > thinking about add Big TCP to raw socket or ICMP datagram socket. I'm not sure
> > what would be a real use case (due MTU limitation is Big TCP mostly used on
> > local networks anyway).
> I think you are mistaken.
> BIG TCP does not have any MTU restrictions and can be used on any network.
> Think about BIG TCP being GSO/TSO/GRO with bigger logical packet sizes.
First, thanks for a quick info. I need to study more BIG TCP. Because I was
wondering if this could be used for sending larger ICMP echo requests > 65k
as it's possible in FreeBSD, where it's done via Jumbograms [1]:
ping -6 -b 70000 -s 68000 ::1
> > I'm asking because I'm just about to limit -s value for ping in iputils (this
> > influences size of payload of ICMP{,v6} being send) to 65507 (IPv4) or 65527 (IPv6):
> > 65507 = 65535 (IPv4 packet size) - 20 (min IPv4 header size) - 8 (ICMP header size)
> > 65527 = 65535 (IPv6 packet size) - 8 (ICMPv6 header size)
> This would involve IP fragmentation, this is orthogonal to GSO/GRO.
But now I'm not sure as GSO/TSO/GRO are in NIC drivers, but this change would be
needed in raw sockets and/or ICMP datagram sockets (net/ipv[46]/{raw,ping}.c).
Also from RFC 8504 point 15. [2] I understood that Jumbograms are not relevant
any more (on FreeBSD it's only for loopback):
15. Removed Jumbograms (RFC 2675) as they aren't deployed.
I guess that's why BIG TCP was created, to have real support anywhere.
Kind regards,
Petr
[1] https://docs.freebsd.org/en/books/developers-handbook/ipv6/#ipv6-jumbo
[2] https://datatracker.ietf.org/doc/html/rfc8504#appendix-A
> > which would then block using Big TCP.
> > The reasons are:
> > 1) The implementation was wrong [1] (signed integer overflow when using
> > INT_MAX).
> > 2) Kernel limits it exactly to these values:
> > * ICMP datagram socket net/ipv4/ping.c in ping_common_sendmsg() [2] (used in
> > both ping_v4_sendmsg() and ping_v6_sendmsg()):
> > if (len > 0xFFFF)
> > return -EMSGSIZE;
> > * raw socket IPv4 in raw_sendmsg() [3]:
> > err = -EMSGSIZE;
> > if (len > 0xFFFF)
> > goto out;
> > * Raw socket IPv6 I suppose either in rawv6_send_hdrinc() [4] (I suppose when
> > IP_HDRINCL set when userspace passes also IP header) or in ip6_append_data() [5]
> > otherwise.
> > 3) Other ping implementations also limit it [6] (I suppose due 2)).
> > Kind regards,
> > Petr
> > [1] https://github.com/iputils/iputils/issues/542
> > [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/ping.c?h=v6.11-rc4#n655
> > [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/raw.c?h=v6.11-rc4#n498
> > [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/raw.c?h=v6.11-rc4#n605
> > [5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/ip6_output.c?h=v6.11-rc4#n1453
> > [6] https://github.com/pevik/iputils/wiki/Maximum-value-for-%E2%80%90s-(size)
Powered by blists - more mailing lists