From: Pavel Begunkov <asml.silence@gmail.com>
To: Stanislav Fomichev <stfomichev@gmail.com>,
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, 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: Thu, 22 May 2025 09:31:04 +0100 [thread overview]
Message-ID: <dd139cb5-3554-4b65-b886-fe648f2413d3@gmail.com> (raw)
In-Reply-To: <aC4OgpSHKf51wQS-@mini-arch>
On 5/21/25 18:33, Stanislav Fomichev wrote:
> 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/
Yes, the patch should work
Reviewed-by: Pavel Begunkov <asml.silence@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.
It might be a good idea to rename it at some point to highlight that
it also works with ubufs (but not as a part of this fix).
--
Pavel Begunkov
next prev parent reply other threads:[~2025-05-22 8:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-20 20:30 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
2025-05-21 18:44 ` Mina Almasry
2025-05-22 8:31 ` Pavel Begunkov [this message]
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=dd139cb5-3554-4b65-b886-fe648f2413d3@gmail.com \
--to=asml.silence@gmail.com \
--cc=almasrymina@google.com \
--cc=andrew+netdev@lunn.ch \
--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=stfomichev@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®