From: Jakub Kicinski <kuba@kernel.org>
To: Yunsheng Lin <linyunsheng@huawei.com>
Cc: <davem@davemloft.net>, <pabeni@redhat.com>,
<liuyonglong@huawei.com>, <fanghaiqing@huawei.com>,
<zhangkun09@huawei.com>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
Robin Murphy <robin.murphy@arm.com>,
Alexander Duyck <alexander.duyck@gmail.com>,
IOMMU <iommu@lists.linux.dev>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
<netdev@vger.kernel.org>, <intel-wired-lan@lists.osuosl.org>,
<bpf@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH net v2 0/2] fix two bugs related to page_pool
Date: Mon, 14 Oct 2024 17:14:06 -0700 [thread overview]
Message-ID: <20241014171406.43e730c9@kernel.org> (raw)
In-Reply-To: <b1fd5ece-b967-4e56-ad4f-64ec437e2634@huawei.com>
On Sat, 12 Oct 2024 20:05:31 +0800 Yunsheng Lin wrote:
> 1. Semantics changing of supporting unlimited inflight pages
> to limited inflight pages that are as large as the pool_size
> of page_pool.
How can this possibly work?
The main thing stopping me from reposting my fix that it'd be nice to
figure out if a real IOMMU device is bound or not. If we don't have
real per-device mappings we presumably don't have to wait. If we can
check this condition we are guaranteed not to introduce regressions,
since we would be replacing a crash by a wait, which is strictly better.
If we'd need to fiddle with too many internals to find out if we have
to wait - let's just always wait and see if anyone complains.
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Yunsheng Lin <linyunsheng@huawei.com>
Cc: linux-mediatek@lists.infradead.org,
Jesper Dangaard Brouer <hawk@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, John Fastabend <john.fastabend@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Alexander Duyck <alexander.duyck@gmail.com>,
linux-kernel@vger.kernel.org,
Alexander Lobakin <aleksander.lobakin@intel.com>,
IOMMU <iommu@lists.linux.dev>,
liuyonglong@huawei.com, Matthias Brugger <matthias.bgg@gmail.com>,
intel-wired-lan@lists.osuosl.org, zhangkun09@huawei.com,
fanghaiqing@huawei.com, bpf@vger.kernel.org, pabeni@redhat.com,
Robin Murphy <robin.murphy@arm.com>,
davem@davemloft.net, linux-arm-kernel@lists.infradead.org,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>
Subject: Re: [Intel-wired-lan] [PATCH net v2 0/2] fix two bugs related to page_pool
Date: Mon, 14 Oct 2024 17:14:06 -0700 [thread overview]
Message-ID: <20241014171406.43e730c9@kernel.org> (raw)
In-Reply-To: <b1fd5ece-b967-4e56-ad4f-64ec437e2634@huawei.com>
On Sat, 12 Oct 2024 20:05:31 +0800 Yunsheng Lin wrote:
> 1. Semantics changing of supporting unlimited inflight pages
> to limited inflight pages that are as large as the pool_size
> of page_pool.
How can this possibly work?
The main thing stopping me from reposting my fix that it'd be nice to
figure out if a real IOMMU device is bound or not. If we don't have
real per-device mappings we presumably don't have to wait. If we can
check this condition we are guaranteed not to introduce regressions,
since we would be replacing a crash by a wait, which is strictly better.
If we'd need to fiddle with too many internals to find out if we have
to wait - let's just always wait and see if anyone complains.
next prev parent reply other threads:[~2024-10-15 0:14 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-25 7:57 [PATCH net v2 0/2] fix two bugs related to page_pool Yunsheng Lin
2024-09-25 7:57 ` [Intel-wired-lan] " Yunsheng Lin
2024-09-25 7:57 ` [PATCH net v2 1/2] page_pool: fix timing for checking and disabling napi_local Yunsheng Lin
2024-09-26 20:06 ` Joe Damato
2024-09-27 3:58 ` Yunsheng Lin
2024-10-01 11:30 ` Paolo Abeni
2024-10-02 1:52 ` Yunsheng Lin
2024-10-09 0:40 ` Jakub Kicinski
2024-10-09 3:33 ` Yunsheng Lin
2024-10-09 15:13 ` Jakub Kicinski
2024-10-10 9:14 ` Yunsheng Lin
2024-09-25 7:57 ` [PATCH net v2 2/2] page_pool: fix IOMMU crash when driver has already unbound Yunsheng Lin
2024-09-25 7:57 ` [Intel-wired-lan] " Yunsheng Lin
2024-09-26 18:15 ` Mina Almasry
2024-09-26 18:15 ` [Intel-wired-lan] " Mina Almasry
2024-09-27 3:57 ` Yunsheng Lin
2024-09-27 3:57 ` [Intel-wired-lan] " Yunsheng Lin
2024-09-27 5:54 ` Mina Almasry
2024-09-27 5:54 ` [Intel-wired-lan] " Mina Almasry
2024-09-27 7:25 ` Yunsheng Lin
2024-09-27 7:25 ` [Intel-wired-lan] " Yunsheng Lin
2024-09-27 9:21 ` Ilias Apalodimas
2024-09-27 9:21 ` [Intel-wired-lan] " Ilias Apalodimas
2024-09-27 9:49 ` Yunsheng Lin
2024-09-27 9:49 ` [Intel-wired-lan] " Yunsheng Lin
2024-09-27 9:58 ` Ilias Apalodimas
2024-09-27 9:58 ` [Intel-wired-lan] " Ilias Apalodimas
2024-09-27 11:29 ` Yunsheng Lin
2024-09-27 11:29 ` [Intel-wired-lan] " Yunsheng Lin
2024-09-28 7:34 ` Ilias Apalodimas
2024-09-28 7:34 ` [Intel-wired-lan] " Ilias Apalodimas
2024-09-29 2:44 ` Yunsheng Lin
2024-09-29 2:44 ` [Intel-wired-lan] " Yunsheng Lin
2024-09-30 8:09 ` Ilias Apalodimas
2024-09-30 8:09 ` [Intel-wired-lan] " Ilias Apalodimas
2024-09-30 8:38 ` Yunsheng Lin
2024-09-30 8:38 ` [Intel-wired-lan] " Yunsheng Lin
2024-10-01 13:32 ` Paolo Abeni
2024-10-01 13:32 ` [Intel-wired-lan] " Paolo Abeni
2024-10-02 2:34 ` Yunsheng Lin
2024-10-02 2:34 ` [Intel-wired-lan] " Yunsheng Lin
2024-10-02 7:37 ` Paolo Abeni
2024-10-02 7:37 ` [Intel-wired-lan] " Paolo Abeni
2024-10-02 8:23 ` Ilias Apalodimas
2024-10-02 8:23 ` [Intel-wired-lan] " Ilias Apalodimas
2024-10-05 12:38 ` Yunsheng Lin
2024-10-05 12:38 ` [Intel-wired-lan] " Yunsheng Lin
2024-10-02 6:46 ` Ilias Apalodimas
2024-10-02 6:46 ` [Intel-wired-lan] " Ilias Apalodimas
2024-10-02 6:51 ` Ilias Apalodimas
2024-10-02 6:51 ` [Intel-wired-lan] " Ilias Apalodimas
2024-09-25 13:31 ` [PATCH net v2 0/2] fix two bugs related to page_pool Yonglong Liu
2024-09-25 13:31 ` [Intel-wired-lan] " Yonglong Liu
2024-10-12 12:05 ` Yunsheng Lin
2024-10-12 12:05 ` [Intel-wired-lan] " Yunsheng Lin
2024-10-15 0:14 ` Jakub Kicinski [this message]
2024-10-15 0:14 ` Jakub Kicinski
2024-10-15 10:52 ` Yunsheng Lin
2024-10-15 10:52 ` [Intel-wired-lan] " 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=20241014171406.43e730c9@kernel.org \
--to=kuba@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=alexander.duyck@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=fanghaiqing@huawei.com \
--cc=hawk@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=iommu@lists.linux.dev \
--cc=john.fastabend@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linyunsheng@huawei.com \
--cc=liuyonglong@huawei.com \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robin.murphy@arm.com \
--cc=zhangkun09@huawei.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 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.