[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230616114710.7e746dea@kernel.org>
Date: Fri, 16 Jun 2023 11:47:10 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jesper Dangaard Brouer <jbrouer@...hat.com>
Cc: Alexander Duyck <alexander.duyck@...il.com>, brouer@...hat.com, Yunsheng
Lin <linyunsheng@...wei.com>, davem@...emloft.net, pabeni@...hat.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Lorenzo Bianconi
<lorenzo@...nel.org>, Jesper Dangaard Brouer <hawk@...nel.org>, Ilias
Apalodimas <ilias.apalodimas@...aro.org>, Eric Dumazet
<edumazet@...gle.com>, Maryam Tahhan <mtahhan@...hat.com>, bpf
<bpf@...r.kernel.org>
Subject: Re: [PATCH net-next v3 3/4] page_pool: introduce page_pool_alloc()
API
On Fri, 16 Jun 2023 20:41:45 +0200 Jesper Dangaard Brouer wrote:
> > This is a sort-of. One thing that has come up as of late is that all
> > this stuff is being moved over to folios anyway and getting away from
> > pages. In addition I am not sure how often we are having to take this
> > path as I am not sure how many non-Tx frames end up having to have
> > fragments added to them. For something like veth it might be more
> > common though since Tx becomes Rx in this case.
>
> I'm thinking, that is it very unlikely that XDP have modified the
> fragments. So, why are we allocating and copying the fragments?
> Wouldn't it be possible for this veth code to bump the refcnt on these
> fragments? (maybe I missed some detail).
They may be page cache pages, AFAIU.
Powered by blists - more mailing lists