From: Stanislav Fomichev <stfomichev@gmail.com>
To: Mina Almasry <almasrymina@google.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, viro@zeniv.linux.org.uk,
horms@kernel.org, andrew+netdev@lunn.ch, shuah@kernel.org,
sagi@grimberg.me, willemb@google.com, asml.silence@gmail.com,
jdamato@fastly.com, kaiyuanz@google.com,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net-next 1/3] net: devmem: support single IOV with sendmsg
Date: Wed, 21 May 2025 10:33:54 -0700 [thread overview]
Message-ID: <aC4OgpSHKf51wQS-@mini-arch> (raw)
In-Reply-To: <CAHS8izOTWF9PO9N6ZamJ0xSCTOojXV+LfYm+5B5b8Ad1MA0QpA@mail.gmail.com>
On 05/21, Mina Almasry wrote:
> On Tue, May 20, 2025 at 1:30 PM Stanislav Fomichev <stfomichev@gmail.com> wrote:
> >
> > sendmsg() with a single iov becomes ITER_UBUF, sendmsg() with multiple
> > iovs becomes ITER_IOVEC. iter_iov_len does not return correct
> > value for UBUF, so teach to treat UBUF differently.
> >
> > Cc: Al Viro <viro@zeniv.linux.org.uk>
> > Cc: Pavel Begunkov <asml.silence@gmail.com>
> > Cc: Mina Almasry <almasrymina@google.com>
> > Fixes: bd61848900bf ("net: devmem: Implement TX path")
> > Signed-off-by: Stanislav Fomichev <stfomichev@gmail.com>
> > ---
> > include/linux/uio.h | 8 +++++++-
> > net/core/datagram.c | 3 ++-
> > 2 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/uio.h b/include/linux/uio.h
> > index 49ece9e1888f..393d0622cc28 100644
> > --- a/include/linux/uio.h
> > +++ b/include/linux/uio.h
> > @@ -99,7 +99,13 @@ static inline const struct iovec *iter_iov(const struct iov_iter *iter)
> > }
> >
> > #define iter_iov_addr(iter) (iter_iov(iter)->iov_base + (iter)->iov_offset)
> > -#define iter_iov_len(iter) (iter_iov(iter)->iov_len - (iter)->iov_offset)
> > +
> > +static inline size_t iter_iov_len(const struct iov_iter *i)
> > +{
> > + if (i->iter_type == ITER_UBUF)
> > + return i->count;
> > + return iter_iov(i)->iov_len - i->iov_offset;
> > +}
> >
>
> This change looks good to me from devmem perspective, but aren't you
> potentially breaking all these existing callers to iter_iov_len?
>
> ackc -i iter_iov_len
> fs/read_write.c
> 846: iter_iov_len(iter), ppos);
> 849: iter_iov_len(iter), ppos);
> 858: if (nr != iter_iov_len(iter))
>
> mm/madvise.c
> 1808: size_t len_in = iter_iov_len(iter);
> 1838: iov_iter_advance(iter, iter_iov_len(iter));
>
> io_uring/rw.c
> 710: len = iter_iov_len(iter);
>
> Or are you confident this change is compatible with these callers for
> some reason?
Pavel did go over all callers, see:
https://lore.kernel.org/netdev/7f06216e-1e66-433e-a247-2445dac22498@gmail.com/
> Maybe better to handle this locally in zerocopy_fill_skb_from_devmem,
> and then follow up with a more ambitious change that streamlines how
> all the iters behave.
Yes, I can definitely do that, but it seems a bit strange that the
callers need to distinguish between IOVEC and UBUF (which is a 1-entry
IOVEC), so having working iter_iov_len seems a bit cleaner.
next prev parent reply other threads:[~2025-05-21 17:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-20 20:30 [PATCH net-next 1/3] net: devmem: support single IOV with sendmsg Stanislav Fomichev
2025-05-20 20:30 ` [PATCH net-next 2/3] selftests: ncdevmem: make chunking optional Stanislav Fomichev
2025-05-21 17:21 ` Mina Almasry
2025-05-21 17:39 ` Stanislav Fomichev
2025-05-21 19:08 ` Mina Almasry
2025-05-20 20:30 ` [PATCH net-next 3/3] selftests: ncdevmem: add tx test with multiple IOVs Stanislav Fomichev
2025-05-21 17:22 ` Mina Almasry
2025-05-21 17:41 ` Stanislav Fomichev
2025-05-21 17:16 ` [PATCH net-next 1/3] net: devmem: support single IOV with sendmsg Mina Almasry
2025-05-21 17:33 ` Stanislav Fomichev [this message]
2025-05-21 18:44 ` Mina Almasry
2025-05-22 8:31 ` Pavel Begunkov
2025-05-28 1:30 ` Jakub Kicinski
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=aC4OgpSHKf51wQS-@mini-arch \
--to=stfomichev@gmail.com \
--cc=almasrymina@google.com \
--cc=andrew+netdev@lunn.ch \
--cc=asml.silence@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jdamato@fastly.com \
--cc=kaiyuanz@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sagi@grimberg.me \
--cc=shuah@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willemb@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.