Re: [PATCH v4 net-next 02/12] ipv6: add IFLA_GSO_IPV6_MAX_SIZE

[Alexander Duyck <alexander.duyck@gmail.com>]

On Fri, May 6, 2022 at 3:26 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 6 May 2022 15:16:21 -0700 Alexander Duyck wrote:
> > On Fri, May 6, 2022 at 2:50 PM Eric Dumazet <edumazet@google.com> wrote:
> > > gso_max_size can not exceed GSO_MAX_SIZE.
> > > This will break many drivers.
> > > I do not want to change hundreds of them.
> >
> > Most drivers will not be impacted because they cannot exceed
> > tso_max_size. The tso_max_size is the limit, not GSO_MAX_SIZE. Last I
> > knew this patch set is overwriting that value to increase it beyond
> > the legacy limits.
> >
> > Right now the check is:
> > if (max_size > GSO_MAX_SIZE || max_size > dev->tso_max_size)
> >
> > What I am suggesting is that tso_max_size be used as the only limit,
> > which is already defaulted to cap out at TSO_LEGACY_MAX_SIZE. So just
> > remove the "max_size > GSO_MAX_SIZE ||" portion of the call. Then when
> > you call netif_set_tso_max_size in the driver to enable jumbograms you
> > are good to set gso_max_size to something larger than the standard
> > 65536.
>
> TBH that was my expectation as well.
>
> Drivers should not pay any attention to dev->gso_* any longer.

Right. However, there are a few protocol items that it looks like do
need to be addressed as SCTP and FCoE appear to be accessing it raw
without any wrappers. So there will be more work than what I called
out to deal with as those would probably need to be wrapped in a min()
function call using the legacy max.

I can take a look at generating the patches if we really want to go
down that route, but it will take me a day or two to get it coded up
as I don't have a ton of free time to work on side projects.