Date: Sat, 10 May 2025 15:49:37 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: "Bjoern A. Zeeb" <bz@freebsd.org> Cc: net@freebsd.org Subject: Re: Can we remove IFCAP_RXCSUM_IPV6? Message-ID: <aB9LYZhUhHsZWRDU@kib.kiev.ua> In-Reply-To: <0np2s799-446r-n801-2os5-oqon276851r2@SerrOFQ.bet> References: <0np2s799-446r-n801-2os5-oqon276851r2@SerrOFQ.bet>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 10, 2025 at 01:37:47AM +0000, Bjoern A. Zeeb wrote: > Hi, > > in 356ab07e2dba0 IFCAP_RXCSUM_IPV6 was introduced along with duplicating > all the other bits to not break hardware offload for IPv4. > > Almost 13 years later I wonder if for any interface (apart from the loopback > interface maybe) IFCAP_RXCSUM_IPV6 ever made any difference? > > A driver would know what RX offload features it can do and one flag should > fit all of them. > > People might say or have said 'but if it is broken for IPv6' we > can no longer disable it. Well, yes we can, in the driver as it doesn't > make sense for an admin of some hardware having to toggle off a broken > feature manually. > > So I wonder if (temporary, say for 15) we can define IFCAP_RXCSUM_IPV6 > to IFCAP_RXCSUM as well, get the bit back as "reserved" during 15 and > then be done with it again? > > I haven't done the full due diligens but a quick grep resulted in a lot > of "same code". > > What am I missing (apart from the painful to do patch)? I think it could be a simplification. Note that we no longer have a shortage of the cap bits, now that there is at least IFCAP2 and full nv-based cap passing ioctl.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aB9LYZhUhHsZWRDU>