From: Jakub Kicinski <kuba@kernel.org>
To: Yunsheng Lin <linyunsheng@huawei.com>
Cc: <davem@davemloft.net>, <pabeni@redhat.com>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
Lorenzo Bianconi <lorenzo@kernel.org>,
Alexander Duyck <alexander.duyck@gmail.com>,
Liang Chen <liangchen.linux@gmail.com>,
Guillaume Tucker <guillaume.tucker@collabora.com>,
Matthew Wilcox <willy@infradead.org>,
Linux-MM <linux-mm@kvack.org>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH net-next v11 1/6] page_pool: fragment API support for 32-bit arch with 64-bit DMA
Date: Mon, 16 Oct 2023 18:31:38 -0700 [thread overview]
Message-ID: <20231016183138.2c4366a7@kernel.org> (raw)
In-Reply-To: <20231013064827.61135-2-linyunsheng@huawei.com>
On Fri, 13 Oct 2023 14:48:21 +0800 Yunsheng Lin wrote:
> Currently page_pool_alloc_frag() is not supported in 32-bit
> arch with 64-bit DMA because of the overlap issue between
> pp_frag_count and dma_addr_upper in 'struct page' for those
> arches, which seems to be quite common, see [1], which means
> driver may need to handle it when using fragment API.
>
> It is assumed that the combination of the above arch with an
> address space >16TB does not exist, as all those arches have
> 64b equivalent, it seems logical to use the 64b version for a
> system with a large address space. It is also assumed that dma
> address is page aligned when we are dma mapping a page aligned
> buffer, see [2].
>
> That means we're storing 12 bits of 0 at the lower end for a
> dma address, we can reuse those bits for the above arches to
> support 32b+12b, which is 16TB of memory.
>
> If we make a wrong assumption, a warning is emitted so that
> user can report to us.
Let me apply this one already, I think it should be uncontroversial
from review perspective. And the more time it gets in linux-next
the better..
next prev parent reply other threads:[~2023-10-17 1:31 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-13 6:48 [PATCH net-next v11 0/6] introduce page_pool_alloc() related API Yunsheng Lin
2023-10-13 6:48 ` Yunsheng Lin
2023-10-13 6:48 ` [PATCH net-next v11 1/6] page_pool: fragment API support for 32-bit arch with 64-bit DMA Yunsheng Lin
2023-10-17 1:31 ` Jakub Kicinski [this message]
2023-10-17 12:05 ` Ilias Apalodimas
2023-10-17 12:17 ` Ilias Apalodimas
2023-10-17 12:53 ` Yunsheng Lin
2023-10-17 13:02 ` Ilias Apalodimas
2023-10-13 6:48 ` [PATCH net-next v11 2/6] page_pool: unify frag_count handling in page_pool_is_last_frag() Yunsheng Lin
2023-10-13 6:48 ` [PATCH net-next v11 3/6] page_pool: remove PP_FLAG_PAGE_FRAG Yunsheng Lin
2023-10-13 6:48 ` [Intel-wired-lan] " Yunsheng Lin
2023-10-13 6:48 ` Yunsheng Lin
2023-10-13 6:48 ` [PATCH net-next v11 4/6] page_pool: introduce page_pool[_cache]_alloc() API Yunsheng Lin
2023-10-13 6:48 ` [PATCH net-next v11 5/6] page_pool: update document about fragment API Yunsheng Lin
2023-10-13 6:48 ` [PATCH net-next v11 6/6] net: veth: use newly added page pool API for veth with xdp Yunsheng Lin
2023-10-17 1:27 ` [PATCH net-next v11 0/6] introduce page_pool_alloc() related API Jakub Kicinski
2023-10-17 1:27 ` Jakub Kicinski
2023-10-17 7:56 ` Yunsheng Lin
2023-10-17 7:56 ` Yunsheng Lin
2023-10-17 15:13 ` Jakub Kicinski
2023-10-17 15:13 ` Jakub Kicinski
2023-10-17 15:14 ` Jakub Kicinski
2023-10-17 15:14 ` Jakub Kicinski
2023-10-18 11:47 ` Yunsheng Lin
2023-10-18 11:47 ` Yunsheng Lin
2023-10-18 15:35 ` Jakub Kicinski
2023-10-18 15:35 ` Jakub Kicinski
2023-10-19 13:22 ` Yunsheng Lin
2023-10-19 13:22 ` Yunsheng Lin
2023-10-19 13:56 ` Jakub Kicinski
2023-10-19 13:56 ` Jakub Kicinski
2023-10-17 4:10 ` patchwork-bot+netdevbpf
2023-10-17 4:10 ` patchwork-bot+netdevbpf
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=20231016183138.2c4366a7@kernel.org \
--to=kuba@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=guillaume.tucker@collabora.com \
--cc=hawk@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=liangchen.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linyunsheng@huawei.com \
--cc=lorenzo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 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.