From: Jason Gunthorpe <jgg@nvidia.com>
To: Mina Almasry <almasrymina@google.com>
Cc: "Yunsheng Lin" <linyunsheng@huawei.com>,
"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: Tue, 14 Nov 2023 09:16:59 -0400 [thread overview]
Message-ID: <ZVNzS2EA4zQRwIQ7@nvidia.com> (raw)
In-Reply-To: <CAHS8izNxkqiNbTA1y+BjQPAber4Dks3zVFNYo4Bnwc=0JLustA@mail.gmail.com>
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 :(
> > I would expect net stack, page pool, driver still see the 'struct page',
> > only memory provider see the specific struct for itself, for the above,
> > devmem memory provider sees the 'struct page_pool_iov'.
> >
> > The reason I still expect driver to see the 'struct page' is that driver
> > will still need to support normal memory besides devmem.
I wouldn't say this approach is unreasonable, but it does have to be
done carefully to isolate the mm. Keeping the struct page in the API
is going to make this very hard.
Jason
next prev parent reply other threads:[~2023-11-14 13:17 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 [this message]
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
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=ZVNzS2EA4zQRwIQ7@nvidia.com \
--to=jgg@nvidia.com \
--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=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).