[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3bba942e-eefd-7ac2-7a8c-b6c349641dd4@huawei.com>
Date: Tue, 12 Oct 2021 15:38:15 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Ilias Apalodimas <ilias.apalodimas@...aro.org>,
Jesper Dangaard Brouer <jbrouer@...hat.com>
CC: John Hubbard <jhubbard@...dia.com>, <davem@...emloft.net>,
<kuba@...nel.org>, <brouer@...hat.com>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linuxarm@...neuler.org>,
<akpm@...ux-foundation.org>, <hawk@...nel.org>,
<peterz@...radead.org>, <yuzhao@...gle.com>, <will@...nel.org>,
<willy@...radead.org>, <jgg@...pe.ca>, <mcroce@...rosoft.com>,
<willemb@...gle.com>, <cong.wang@...edance.com>,
<pabeni@...hat.com>, <haokexin@...il.com>, <nogikh@...gle.com>,
<elver@...gle.com>, <memxor@...il.com>, <vvs@...tuozzo.com>,
<linux-mm@...ck.org>, <edumazet@...gle.com>,
<alexander.duyck@...il.com>, <dsahern@...il.com>
Subject: Re: [PATCH net-next -v5 3/4] mm: introduce __get_page() and
__put_page()
On 2021/10/11 20:29, Ilias Apalodimas wrote:
> On Mon, Oct 11, 2021 at 02:25:08PM +0200, Jesper Dangaard Brouer wrote:
>>
>>
>> On 09/10/2021 21.49, John Hubbard wrote:
>>> So in case it's not clear, I'd like to request that you drop this one
>>> patch from your series.
>>
>> In my opinion as page_pool maintainer, you should also drop patch 4/4 from
>> this series.
>>
>> I like the first two patches, and they should be resend and can be applied
>> without too much further discussion.
>
> +1
Ok, it seems there is a lot of contention about how to avoid calling
compound_head() now.
Will send out the uncontroversial one first.
> That's what I hinted on the previous version. The patches right now go way
> beyond the spec of page pool. We are starting to change core networking
> functions and imho we need a lot more people involved in this discussion,
> than the ones participating already.
>
> As a general note and the reason I am so hesitant, is that we are starting
> to violate layers here (at least in my opinion). When the recycling was
> added, my main concern was to keep the network stack unaware (apart from
> the skb bit). Now suddenly we need to teach frag_ref/unref internal page
Maybe the skb recycle bit is a clever way to avoid dealing with the network
stack directly.
But that bit might also introduce or hide some problem, like the data race
as pointed out by Alexander, and the odd using of page pool in mlx5 driver.
> pool counters and that doesn't feel right. We first need to prove the race
> can actually happen, before starting to change things.
As the network stack is adding a lot of performance improvement, such as
sockmap for BPF, which may cause problem for them, will dig more to prove
that.
>
> Regards
> /Ilias
>>
>> --Jesper
>>
> .
>
Powered by blists - more mailing lists