[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d2015724-416b-4222-aa85-88c0c5f9160c@ti.com>
Date: Thu, 21 Aug 2025 16:18:07 +0530
From: Meghana Malladi <m-malladi@...com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <namcao@...utronix.de>, <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>, <pabeni@...hat.com>,
<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: [PATCH net-next 5/6] net: ti: icssg-prueth: Add AF_XDP zero copy
for RX
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 ?
Powered by blists - more mailing lists