[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1e1d368c-5a52-421c-9022-57166a8a3340@gmail.com>
Date: Tue, 10 Dec 2024 04:15:13 +0000
From: Pavel Begunkov <asml.silence@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: David Wei <dw@...idwei.uk>, io-uring@...r.kernel.org,
netdev@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
Paolo Abeni <pabeni@...hat.com>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jesper Dangaard Brouer
<hawk@...nel.org>, David Ahern <dsahern@...nel.org>,
Mina Almasry <almasrymina@...gle.com>,
Stanislav Fomichev <stfomichev@...il.com>, Joe Damato <jdamato@...tly.com>,
Pedro Tammela <pctammela@...atatu.com>
Subject: Re: [PATCH net-next v8 04/17] net: prepare for non devmem TCP memory
providers
On 12/10/24 04:06, Jakub Kicinski wrote:
> On Tue, 10 Dec 2024 03:53:36 +0000 Pavel Begunkov wrote:
>>>> @@ -353,16 +356,16 @@ void page_pool_unlist(struct page_pool *pool)
>>>> int page_pool_check_memory_provider(struct net_device *dev,
>>>> struct netdev_rx_queue *rxq)
>>>> {
>>>> - struct net_devmem_dmabuf_binding *binding = rxq->mp_params.mp_priv;
>>>> + void *mp_priv = rxq->mp_params.mp_priv;
>>>> struct page_pool *pool;
>>>> struct hlist_node *n;
>>>>
>>>> - if (!binding)
>>>> + if (!mp_priv)
>>>> return 0;
>>>>
>>>> mutex_lock(&page_pools_lock);
>>>> hlist_for_each_entry_safe(pool, n, &dev->page_pools, user.list) {
>>>> - if (pool->mp_priv != binding)
>>>> + if (pool->mp_priv != mp_priv)
>>>> continue;
>>>>
>>>> if (pool->slow.queue_idx == get_netdev_rx_queue_index(rxq)) {
>>>
>>> appears to be unrelated
>>
>> The entire chunk? It removes the type, nobody should be blindly casting
>> it to devmem specific binding even if it's not referenced, otherwise it
>> gets pretty ugly pretty fast. E.g. people might assume that it's always
>> the right type to cast to.
>
> Change is good. It didn't feel very related to the other changes
> which specifically address devmem code. While this one only removes
> the type because the code itself isn't devmem specific. Right?
Right, and nobody cared because there wasn't anyone but devmem
prior to the series.
> if you make this chunk a separate patch #1 in the series I can apply it
> right away. pp->mp_priv is void *, this is a good cleanup regardless.
I can throw it into a separate patch, though let's just keep
it in the series as it'd complicate merging otherwise. Let's
say if it doesn't land this release, I'll send it separately
with 1/17 as clean ups.
--
Pavel Begunkov
Powered by blists - more mailing lists