From: Toke Høiland-Jørgensen <toke@xxxxxxxxxx> Date: Fri, 10 Feb 2023 19:09:12 +0100 > Alexander Lobakin <alexandr.lobakin@xxxxxxxxx> writes: > >> The set grew from the poor performance of %BPF_F_TEST_XDP_LIVE_FRAMES >> when the ice-backed device is a sender. Initially there were around >> 3.3 Mpps / thread, while I have 5.5 on skb-based pktgen... >> >> After fixing 0005 (0004 is a prereq for it) first (strange thing nobody >> noticed that earlier), I started catching random OOMs. This is how 0002 >> (and partially 0001) appeared. >> 0003 is a suggestion from Maciej to not waste time on refactoring dead >> lines. 0006 is a "cherry on top" to get away with the final 6.7 Mpps. >> 4.5 of 6 are fixes, but only the first three are tagged, since it then >> starts being tricky. I may backport them manually later on. >> >> TL;DR for the series is that shortcuts are good, but only as long as >> they don't make the driver miss important things. %XDP_TX is purely >> driver-local, however .ndo_xdp_xmit() is not, and sometimes assumptions >> can be unsafe there. >> >> With that series and also one core code patch[0], "live frames" and >> xdp-trafficgen are now safe'n'fast on ice (probably more to come). > > Nice speedup! And cool to see that you're playing around with > xdp-trafficgen :) It's not only good for bombing receivers without any special HW, but also for uncovering problems with XDP in drivers and/or kernel core, as I can see :D > > -Toke > Thanks, Olek