Re: [PATCH net-next v4 2/2] net: prevent mixing frags from different memory providers or bindings

[Stanislav Fomichev <sdf.kernel@gmail.com>]

On 11/11, Mina Almasry wrote:
> On Tue, Nov 10, 2026 at 7:54 PM Mina Almasry <almasrymina@google.com> wrote:
> >
> > On Mon, Nov 9, 2026 at 10:33 AM Stanislav Fomichev <sdf.kernel@gmail.com> wrote:
> > > > --- a/net/ipv4/tcp_output.c
> > > > +++ b/net/ipv4/tcp_output.c
> > > > @@ -2692,8 +2692,9 @@ static int tcp_clone_payload(struct sock *sk, struct sk_buff *to,
> > > >                                    probe_size - len);
> > > >                       len += todo;
> > > >                       skb_shinfo(to)->flags |= skb_shinfo(skb)->flags & SKBFL_SHARED_FRAG;
> > > > +                     to->unreadable |= skb->unreadable;
> > > >                       if (lastfrag &&
> > > > -                         skb_frag_page(fragfrom) == skb_frag_page(lastfrag) &&
> > > > +                         skb_frag_netmem(fragfrom) == skb_frag_netmem(lastfrag) &&
> > > >                           skb_frag_off(fragfrom) == skb_frag_off(lastfrag) +
> > > >                                                     skb_frag_size(lastfrag)) {
> > > >                               skb_frag_size_add(lastfrag, todo);
> > >
> > > From [0]:
> > >
> > > Maybe easier to not merge niovs here? Add '&& !skb_frag_is_net_iov' to
> > > that 'if (lastfrag' check? (or your new skb_has_net_iovs)
> > >
> > > Looks like it is tcp_mtu_probe path, not sure we care about merging there?
> >
> > I'm guessing this is not an issue with pages because they're
> > PAGE_SIZE? But, seems maybe a bit lazy to just hammer all possible
> > net-iov coalescing? Is there a slightly cleaner and more generic check
> > ( && skb_frag_size < PAGE_SIZE or something) so that we don't add
> > net-iov tech debt? Technically this will be an issue for hugepages in
> > the tx path or large folios or something.
> >
> > Also I think it belongs in your patch series maybe. That's the one
> > adding the large niovs :P
> >
> 
> Actually, this comment made me realize: is the optimization that you
> did with net-iovs here (that's showing so much better cpu) also
> already implemented for pages? If not, is it possible? I don't see in
> theory why the userpsace can't pass in a contingious 2MB page to
> sendmsg() and the stack could keep it intact in 1 frag up to what the
> driver tx supports, no? Is it worth it making your feature generic and
> apply to pages too?

Based on [0] I'm thinking that I'll drop all per-frag enforcement
and will not add any special handing to tcp_mtu_probes. Looks like
the drivers are expected to handle large frags (if they advertise
large tso) or have a [1]-like segmentation fallback signal to the stack..

And yes, regular msg_zerocopy path already merges pages so this is
not niov specific.

0: https://lore.kernel.org/netdev/20261105222058.944293-1-sdf@fomichev.me/T/#m169832053b43604b0c5df7f7b1d04e9d4f390cbc
1: https://lore.kernel.org/netdev/20261105222058.944293-1-sdf@fomichev.me/T/#mb6e882ab1aecd6c15552773653301cc235b987d8