[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7fcb1434-2ff1-408c-934b-9b87cee926c8@ti.com>
Date: Wed, 5 Nov 2025 12:12:06 +0530
From: Meghana Malladi <m-malladi@...com>
To: Jakub Kicinski <kuba@...nel.org>
CC: Paolo Abeni <pabeni@...hat.com>, <horms@...nel.org>,
<namcao@...utronix.de>, <vadim.fedorenko@...ux.dev>,
<jacob.e.keller@...el.com>, <christian.koenig@....com>,
<sumit.semwal@...aro.org>, <sdf@...ichev.me>, <john.fastabend@...il.com>,
<hawk@...nel.org>, <daniel@...earbox.net>, <ast@...nel.org>,
<edumazet@...gle.com>, <davem@...emloft.net>, <andrew+netdev@...n.ch>,
<linaro-mm-sig@...ts.linaro.org>, <dri-devel@...ts.freedesktop.org>,
<linux-media@...r.kernel.org>, <bpf@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <srk@...com>, Vignesh Raghavendra
<vigneshr@...com>, Roger Quadros <rogerq@...nel.org>, <danishanwar@...com>
Subject: Re: [EXTERNAL] Re: [PATCH net-next v4 2/6] net: ti: icssg-prueth: Add
XSK pool helpers
Hi Jakub,
On 11/5/25 05:18, Jakub Kicinski wrote:
> On Tue, 4 Nov 2025 14:23:24 +0530 Meghana Malladi wrote:
>>> I tried honoring Jakub's comment to avoid freeing the rx memory wherever
>>> necessary.
>>>
>>> "In case of icssg driver, freeing the rx memory is necessary as the
>>> rx descriptor memory is owned by the cppi dma controller and can be
>>> mapped to a single memory model (pages/xdp buffers) at a given time.
>>> In order to remap it, the memory needs to be freed and reallocated."
>>
>> Just to make sure we are on the same page, does the above explanation
>> make sense to you or do you want me to make any changes in this series
>> for v5 ?
>
> No. Based on your reply below you seem to understand what is being
> asked, so you're expected to do it.
>
Yes, this series currently implements whatever Paolo mentioned below.
>>>> I think you should:
>>>> - stop the H/W from processing incoming packets,
>>>> - spool all the pending packets
>>>> - attach/detach the xsk_pool
>>>> - refill the ring
>>>> - re-enable the H/W
>>>
>>> Current implementation follows the same sequence:
>>> 1. Does a channel teardown -> stop incoming traffic
>>> 2. free the rx descriptors from free queue and completion queue -> spool
>>> all pending packets/descriptors
>>> 3. attach/detach the xsk pool
>>> 4. allocate rx descriptors and fill the freeq after mapping them to the
>>> correct memory buffers -> refill the ring
>>> 5. restart the NAPI - re-enable the H/W to recv the traffic
>>>
Sorry for the confusion. Whatever I mentioned below might have given an
impression that there was additional required work; that wasn’t my
intention. What I described is only a possible design enhancement and
not mandatory. The current patch series is complete and does not have
gaps in its design.
>>> I am still working on skipping 2 and 4 steps but this will be a long
>>> shot. Need to make sure all corner cases are getting covered. If this
>>> approach looks doable without causing any regressions I might post it as
>>> a followup patch later in the future.
Powered by blists - more mailing lists