On 2/2/24 3:46 PM, Jens Axboe wrote: > On 2/2/24 3:20 PM, Jens Axboe wrote: >> On 2/2/24 1:23 PM, Olivier Langlois wrote: >>> On Fri, 2024-02-02 at 13:14 -0700, Jens Axboe wrote: >>>> >>>> Ah gotcha, yeah that?s odd and could not ever have worked. I wonder >>>> how that was tested? >>>> >>>> I?ll setup a liburing branch as well. >>>> >>> It is easy. You omit to check the function return value by telling to >>> yourself that it cannot fail... >>> >>> I caught my mistake on a second pass code review... >> >> Oh I can see how that can happen, but then there should be no functional >> changes in terms of latency... Which means that it was never tested. The >> test results were from the original postings, so probably just fine. >> It's just that later versions would've failed. Looking at the example >> test case, it doesn't check the return value. > > Setup a 'napi' branch with the patches, and some fixes on top. It's a > start... I'll try the example ping test here, just need to get off a > plane and be able to access test boxes. Added ipv4 support to the napi example code, and here's what I get. Stock settings, no NAPI, 100k packets: rtt(us) min/avg/max/mdev = 31.730/37.006/87.960/0.497 and with -t10 -b enabled: rtt(us) min/avg/max/mdev = 23.250/29.795/63.511/1.203 So it seems to work fine as-is, with the current branch. I've added some tweaks on the liburing napi branch, but mostly just little fixes. -- Jens Axboe
