On Wed, May 12, 2021 at 10:26 AM Benoit Ganne (bganne) <bganne@xxxxxxxxx> wrote: > > Hi Magnus, > > >> I am the maintainer of the AF_XDP driver for VPP, an open-source > >> userspace networking stack, and I ran into an issue recently with kernels > >> < 5.6 (including LTS kernel 5.4 which is shipped in eg. Ubuntu 20.04 LTS): > >> it seems like one cannot call poll() and sendmsg() concurrently on the > >> same AF_XDP socket. Is this a supported usecase? > [...] > >> I hit a 2nd issue with kernel >= 5.9, where the headroom on rx for copy > >> mode has grown from 0 to XDP_PACKET_HEADROOM (256-bytes). > [...] > > > Hi Benoit. Thank you for reporting, I will take a look at this and get > > back to you. Next time, please add me and Björn on the to line so that > > you get a quicker response. > > Thanks! Sure I will in the future. > If I may, an ideal scenario would be: > 1) the concurrent rx/tx usecase is officially supported, and 11cc2d21499cabe7e7964389634ed1de3ee91d33 should be backported to LTS I will fix this. The (unintentional) fix you refer to should apply cleanly to 5.4 and 4.19 LTS kernels. I just have to verify this and submit a request to Greg. Probably with a new commit message that describes what problem it fixes, since it is not just a simplification anymore. > 2) had a way to detect different version of AF_XDP (through an ioctl() or getsockopt() or...) so that I can detect more easily what I should do at init time. Eg. managing both headroom (0 and 256) for copy mode is not very difficult if I can detect it easily Björn and I have yet to come up with a good way to detect this that does not involve receiving a packet. Another possible way would be to backport a fix for this to 5.4 and 4.19 LTS too. But this seems to be a less straightforward patch, so let us see what that would entail. Björn is working on this and will get back to you. > > Best > ben
