From: Yunsheng Lin <linyunsheng@huawei.com>
To: Mina Almasry <almasrymina@google.com>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Jason Gunthorpe" <jgg@nvidia.com>,
"Christian König" <christian.koenig@amd.com>,
"Shakeel Butt" <shakeelb@google.com>,
"Willem de Bruijn" <willemdebruijn.kernel@gmail.com>
Subject: Re: [RFC PATCH net-next v5 2/2] net: add netmem to skb_frag_t
Date: Fri, 12 Jan 2024 19:51:20 +0800 [thread overview]
Message-ID: <0711845b-c435-251f-0bbc-20b243721c06@huawei.com> (raw)
In-Reply-To: <CAHS8izOtr+jfqQ6xCB3CoN-K_V1-4hPsB4-k5+1z-M3Qy2BbwA@mail.gmail.com>
On 2024/1/12 8:34, Mina Almasry wrote:
> On Thu, Jan 11, 2024 at 4:45 AM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>>
>> On 2024/1/9 9:14, Mina Almasry wrote:
>>
>> ...
>>
>>>
>>> + if (WARN_ON_ONCE(!skb_frag_page(&skb_shinfo(skb)->frags[0]))) {
>>
>> I am really hate to bring it up again.
>> If you are not willing to introduce a new helper,
>
> I'm actually more than happy to add a new helper like:
>
> static inline netmem_ref skb_frag_netmem();
>
> For future callers to obtain frag->netmem to use the netmem_ref directly.
>
> What I'm hung up on is really your follow up request:
>
> "Is it possible to introduce something like skb_frag_netmem() for
> netmem? so that we can keep most existing users of skb_frag_page()
> unchanged and avoid adding additional checking overhead for existing
> users."
>
> With this patchseries, skb_frag_t no longer has a page pointer inside
> of it, it only has a netmem_ref. The netmem_ref is currently always a
> page, but in the future may not be a page. Can you clarify how we keep
> skb_frag_page() unchanged and without checks? What do you expect
> skb_frag_page() and its callers to do? We can not assume netmem_ref is
> always a struct page. I'm happy to implement a change but I need to
> understand it a bit better.
There are still many existing places still not expecting or handling
skb_frag_page() returning NULL, mostly those are in the drivers not
supporting devmem, what's the point of adding the extral overhead for
those driver?
The networking stack should forbid skb with devmem frag being forwarded
to drivers not supporting devmem yet. I am sure if this is done properly
in your patchset yet? if not, I think you might to audit every existing
drivers handling skb_frag_page() returning NULL correctly.
>
>> do you care to use some
>> existing API like skb_frag_address_safe()?
>>
>
> skb_frag_address_safe() checks that the page is mapped. In this case,
> we are not checking if the frag page is mapped; we would like to make
> sure that the skb_frag has a page inside of it in the first place.
> Seems like a different check from skb_frag_address_safe().
>
> In fact, skb_frag_address[_safe]() actually assume that the skb frag
> is always a page currently, I think I need to squash this fix:
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index e59f76151628..bc8b107d0235 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -3533,7 +3533,9 @@ static inline void skb_frag_unref(struct sk_buff
> *skb, int f)
> */
> static inline void *skb_frag_address(const skb_frag_t *frag)
> {
> - return page_address(skb_frag_page(frag)) + skb_frag_off(frag);
> + return skb_frag_page(frag) ?
> + page_address(skb_frag_page(frag)) + skb_frag_off(frag) :
> + NULL;
> }
>
> /**
> @@ -3545,7 +3547,14 @@ static inline void *skb_frag_address(const
> skb_frag_t *frag)
> */
> static inline void *skb_frag_address_safe(const skb_frag_t *frag)
> {
> - void *ptr = page_address(skb_frag_page(frag));
> + struct page *page;
> + void *ptr;
> +
> + page = skb_frag_page(frag);
> + if (!page)
> + return NULL;
> +
> + ptr = page_address(skb_frag_page(frag));
> if (unlikely(!ptr))
> return NULL;
>
>>> + ret = -EINVAL;
>>> + goto out;
>>> + }
>>> +
>>> iov_iter_bvec(&msg.msg_iter, ITER_SOURCE,
>>> - skb_shinfo(skb)->frags, skb_shinfo(skb)->nr_frags,
>>> - msize);
>>> + (const struct bio_vec *)skb_shinfo(skb)->frags,
>>> + skb_shinfo(skb)->nr_frags, msize);
>>
>> I think we need to use some built-time checking to ensure some consistency
>> between skb_frag_t and bio_vec.
>>
>
> I can add static_assert() that bio_vec->bv_len & bio_vec->bv_offset
> are aligned with skb_frag_t->len & skb_frag_t->offset.
>
> I can also maybe add a helper skb_frag_bvec() to do the cast instead
> of doing it at the calling site. That may be a bit cleaner.
I think the more generic way to do is to add something like iov_iter_netmem()
instead of doing any cast, so that netmem can be decoupled from bvec completely.
>
>>> iov_iter_advance(&msg.msg_iter, txm->frag_offset);
>>>
>>> do {
>>>
>
>
>
> --
> Thanks,
> Mina
> .
>
next prev parent reply other threads:[~2024-01-12 11:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-09 1:14 [RFC PATCH net-next v5 0/2] Abstract page from net stack Mina Almasry
2024-01-09 1:14 ` [RFC PATCH net-next v5 1/2] net: introduce abstraction for network memory Mina Almasry
2024-01-10 18:45 ` Shakeel Butt
2024-01-09 1:14 ` [RFC PATCH net-next v5 2/2] net: add netmem to skb_frag_t Mina Almasry
2024-01-11 12:44 ` Yunsheng Lin
2024-01-12 0:34 ` Mina Almasry
2024-01-12 11:51 ` Yunsheng Lin [this message]
2024-01-12 15:35 ` Mina Almasry
2024-01-15 9:37 ` Yunsheng Lin
2024-01-15 23:23 ` Mina Almasry
2024-01-16 0:01 ` Jason Gunthorpe
2024-01-16 11:04 ` Yunsheng Lin
2024-01-16 12:16 ` Jason Gunthorpe
2024-01-17 9:28 ` Yunsheng Lin
2024-01-17 18:00 ` Mina Almasry
2024-01-17 18:34 ` Mina Almasry
2024-01-17 18:54 ` Willem de Bruijn
2024-01-18 8:52 ` Yunsheng Lin
2024-01-18 13:56 ` Mina Almasry
2024-01-10 2:03 ` [RFC PATCH net-next v5 0/2] Abstract page from net stack 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=0711845b-c435-251f-0bbc-20b243721c06@huawei.com \
--to=linyunsheng@huawei.com \
--cc=almasrymina@google.com \
--cc=christian.koenig@amd.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jgg@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shakeelb@google.com \
--cc=willemdebruijn.kernel@gmail.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®