From: David Ahern <dsahern@kernel.org>
To: Yunsheng Lin <linyunsheng@huawei.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Mina Almasry <almasrymina@google.com>
Cc: "Jakub Kicinski" <kuba@kernel.org>,
davem@davemloft.net, pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Willem de Bruijn" <willemb@google.com>,
"Kaiyuan Zhang" <kaiyuanz@google.com>,
"Jesper Dangaard Brouer" <hawk@kernel.org>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
"Eric Dumazet" <edumazet@google.com>,
"Christian König" <christian.koenig@amd.com>,
"Matthew Wilcox" <willy@infradead.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH RFC 3/8] memory-provider: dmabuf devmem memory provider
Date: Wed, 15 Nov 2023 10:57:30 -0700 [thread overview]
Message-ID: <ee10d050-ef24-49b2-8712-c9bc8a911c2a@kernel.org> (raw)
In-Reply-To: <ed875644-95e8-629a-4c28-bf42329efa56@huawei.com>
On 11/15/23 2:21 AM, Yunsheng Lin wrote:
> On 2023/11/14 21:16, Jason Gunthorpe wrote:
>> On Tue, Nov 14, 2023 at 04:21:26AM -0800, Mina Almasry wrote:
>>
>>> Actually because you put the 'strtuct page for devmem' in
>>> skb->bv_frag, the net stack will grab the 'struct page' for devmem
>>> using skb_frag_page() then call things like page_address(), kmap,
>>> get_page, put_page, etc, etc, etc.
>>
>> Yikes, please no. If net has its own struct page look alike it has to
>> stay entirely inside net. A non-mm owned struct page should not be
>> passed into mm calls. It is just way too hacky to be seriously
>> considered :(
>
> Yes, that is something this patchset is trying to do, defining its own
> struct page look alike for page pool to support devmem.
>
Networking needs to be able to move away from struct page references.
The devmem and host memory for Rx use cases do not need to be page based.
next prev parent reply other threads:[~2023-11-15 17:57 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-13 13:00 [PATCH RFC 0/8] A possible proposal for intergating dmabuf to page pool Yunsheng Lin
2023-11-13 13:00 ` [PATCH RFC 1/8] net: page_pool: factor out releasing DMA from releasing the page Yunsheng Lin
2023-11-13 13:00 ` [PATCH RFC 2/8] net: page_pool: create hooks for custom page providers Yunsheng Lin
2023-11-13 13:00 ` [PATCH RFC 3/8] memory-provider: dmabuf devmem memory provider Yunsheng Lin
2023-11-13 13:42 ` Mina Almasry
2023-11-13 23:05 ` Jakub Kicinski
2023-11-14 8:23 ` Yunsheng Lin
2023-11-14 12:21 ` Mina Almasry
2023-11-14 12:49 ` Yunsheng Lin
2023-11-14 12:58 ` Mina Almasry
2023-11-14 13:19 ` Yunsheng Lin
2023-11-14 15:41 ` Willem de Bruijn
2023-11-15 9:29 ` Yunsheng Lin
2023-11-15 18:07 ` Mina Almasry
2023-11-15 19:05 ` Mina Almasry
2023-11-16 11:12 ` Yunsheng Lin
2023-11-16 11:30 ` Mina Almasry
2023-11-14 13:16 ` Jason Gunthorpe
2023-11-15 6:46 ` Christian König
2023-11-15 9:21 ` Yunsheng Lin
2023-11-15 13:38 ` Jason Gunthorpe
2023-11-16 11:10 ` Yunsheng Lin
2023-11-16 15:31 ` Jason Gunthorpe
2023-11-15 17:44 ` Mina Almasry
2023-11-16 11:11 ` Yunsheng Lin
2023-11-15 17:57 ` David Ahern [this message]
2023-11-16 11:12 ` Yunsheng Lin
2023-11-16 15:58 ` David Ahern
2023-11-17 11:27 ` Yunsheng Lin
2023-11-14 22:25 ` Jakub Kicinski
2023-11-15 9:33 ` Yunsheng Lin
2023-11-13 13:00 ` [PATCH RFC 4/8] skbuff: explicitize the semantics of skb_frag_fill_page_desc() Yunsheng Lin
2023-11-13 13:00 ` [PATCH RFC 5/8] skbuff: remove compound_head() related function calling Yunsheng Lin
2023-11-13 13:00 ` [PATCH RFC 6/8] skbuff: always try to do page pool frag reference counting Yunsheng Lin
2023-11-13 13:00 ` [PATCH RFC 7/8] net: hns3: temp hack for hns3 to use dmabuf memory provider Yunsheng Lin
2023-11-13 13:00 ` [PATCH RFC 8/8] net: temp hack for dmabuf page in __skb_datagram_iter() Yunsheng Lin
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=ee10d050-ef24-49b2-8712-c9bc8a911c2a@kernel.org \
--to=dsahern@kernel.org \
--cc=almasrymina@google.com \
--cc=christian.koenig@amd.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=jgg@nvidia.com \
--cc=kaiyuanz@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linyunsheng@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemb@google.com \
--cc=willy@infradead.org \
/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).