Re: [PATCH net-next 5/6] net: ti: icssg-prueth: Add AF_XDP zero copy for RX

[Meghana Malladi <m-malladi@ti.com>]

Hi Jakub,

On 8/19/25 20:05, Jakub Kicinski wrote:
> On Mon, 18 Aug 2025 16:54:23 +0530 Meghana Malladi wrote:
>> @@ -1332,6 +1350,13 @@ static int prueth_xsk_wakeup(struct net_device *ndev, u32 qid, u32 flags)
>>   		}
>>   	}
>>   
>> +	if (flags & XDP_WAKEUP_RX) {
>> +		if (!napi_if_scheduled_mark_missed(&emac->napi_rx)) {
>> +			if (likely(napi_schedule_prep(&emac->napi_rx)))
>> +				__napi_schedule(&emac->napi_rx);
>> +		}
>> +	}
>> +
>>   	return 0;
> 
> I suspect this series is generated against old source or there's
> another conflicting series in flight, because git ends up applying
> this chunk to prueth_xsk_pool_disable() :S
> 

That's interesting. I have directly applied these patches locally on the 
tip of net-next (62a2b3502573 "net: openvswitch: Use for_each_cpu() 
where appropriate") And everything gets applied cleanly and I couldn't 
reproduce the issue you mentioned above. Can you tell me on top of which 
commit you tried applying this series ? Or I wonder if this happened 
because I posted this series from my net tree instead of net-next. Does 
it make sense to re-post the same patches from net-next tree ?

> Before you proceed with AF_XDP could you make this driver build under
> COMPILE_TEST on x86? This is very easy to miss, luckily we got an off
> list report but its pure luck. And obviously much more effort for the
> maintainers to investigate than if it was caught by the CI.

I have tried what you have suggested and these are the logs for the 
same: 
https://gist.github.com/MeghanaMalladiTI/8a3f64773d96e58aec48aca78c1bc98c

ICSSG driver as a module has been compiled without any errors but 
encountered few linking errors due to some missing symbols from another 
module (CONFIG_TI_K3_UDMA). I included this module in the next iteration 
and tried compiling but facing some build failures, logs: 
https://gist.github.com/MeghanaMalladiTI/f7ed3958b5ab2b2be479151254015ff0

I think it is safe to assume ICSSG as a driver build on x86 doesn't have 
build regressions, thoughts ? Also is this something which needs to be 
done by us everytime we are posting some feature upstream or does Kernel 
CI take care of it ?