From: Leon Romanovsky <leon@kernel.org>
To: Ilia Lin <ilia.lin@kernel.org>
Cc: steffen.klassert@secunet.com, herbert@gondor.apana.org.au,
davem@davemloft.net, dsahern@kernel.org, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xfrm: Add pre-encap fragmentation for packet offload
Date: Mon, 25 Nov 2024 21:43:40 +0200 [thread overview]
Message-ID: <20241125194340.GI160612@unreal> (raw)
In-Reply-To: <CA+5LGR2n-jCyGbLy9X5wQoUT5OXPkAc3nOr9bURO6=9ObEZVnA@mail.gmail.com>
On Mon, Nov 25, 2024 at 11:26:14AM +0200, Ilia Lin wrote:
> On Sun, Nov 24, 2024 at 2:04 PM Leon Romanovsky <leon@kernel.org> wrote:
> >
> > On Sun, Nov 24, 2024 at 11:35:31AM +0200, Ilia Lin wrote:
> > > In packet offload mode the raw packets will be sent to the NiC,
> > > and will not return to the Network Stack. In event of crossing
> > > the MTU size after the encapsulation, the NiC HW may not be
> > > able to fragment the final packet.
> >
> > Yes, HW doesn't know how to handle these packets.
> >
> > > Adding mandatory pre-encapsulation fragmentation for both
> > > IPv4 and IPv6, if tunnel mode with packet offload is configured
> > > on the state.
> >
> > I was under impression is that xfrm_dev_offload_ok() is responsible to
> > prevent fragmentation.
> > https://elixir.bootlin.com/linux/v6.12/source/net/xfrm/xfrm_device.c#L410
>
> With my change we can both support inner fragmentation or prevent it,
> depending on the network device driver implementation.
The thing is that fragmentation isn't desirable thing. Why didn't PMTU
take into account headers so we can rely on existing code and do not add
extra logic for packet offload?
Thanks
>
> >
> > Thanks
next prev parent reply other threads:[~2024-11-25 19:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-24 9:35 [PATCH] xfrm: Add pre-encap fragmentation for packet offload Ilia Lin
2024-11-24 12:04 ` Leon Romanovsky
2024-11-25 9:26 ` Ilia Lin
2024-11-25 19:43 ` Leon Romanovsky [this message]
2024-11-26 7:48 ` Ilia Lin
[not found] ` <CA+5LGR0e677wm5zEx9yYZDtsCUL6etMoRB2yF9o5msqdVOWU8w@mail.gmail.com>
2024-11-26 8:35 ` Leon Romanovsky
2024-11-26 12:59 ` Steffen Klassert
2024-11-26 13:21 ` Leon Romanovsky
2024-11-28 9:25 ` Steffen Klassert
2024-11-28 12:14 ` Leon Romanovsky
2024-11-26 12:51 ` Steffen Klassert
2024-11-26 13:22 ` Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241125194340.GI160612@unreal \
--to=leon@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=horms@kernel.org \
--cc=ilia.lin@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).