[EXTERNAL] Re: [PATCH net-next v4 2/6] net: ti: icssg-prueth: Add XSK pool helpers

[Meghana Malladi]

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.