<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 01/03/2024 15:43, Loftus, Ciara wrote: </div> <blockquote type="cite" cite="mid:MW4PR11MB58728DB7098730D0C5D28BDD8E5E2@MW4PR11MB5872.namprd11.prod.outlook.com"> <pre class="moz-quote-pre" wrap="">snip </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">@@ -1695,17 +1699,16 @@ xsk_configure(struct pmd_internals *internals, struct pkt_rx_queue *rxq, } if (internals->use_cni) { - int err, fd, map_fd; + int err, map_fd; - /* get socket fd from CNI plugin */ - map_fd = get_cni_fd(internals->if_name); + /* get socket fd from AF_XDP Device Plugin */ + map_fd = uds_get_xskmap_fd(internals->if_name, internals- </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">dp_path); </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> if (map_fd < 0) { - AF_XDP_LOG(ERR, "Failed to receive CNI plugin fd\n"); + AF_XDP_LOG(ERR, "Failed to receive xskmap fd from AF_XDP Device Plugin\n"); goto out_xsk; } - /* get socket fd */ - fd = xsk_socket__fd(rxq->xsk); - err = bpf_map_update_elem(map_fd, &rxq->xsk_queue_idx, &fd, 0); + + err = xsk_socket__update_xskmap(rxq->xsk, map_fd); </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Hi Maryam, I've reviewed the series again. I haven't tested the device-plugin specific functionality as I don't have that environment set up, but outside of that I am happy that the new functionality doesn't break anything else. The doc updates look good to me now, thank you for the fixes. I have just spotted one issue and I apologise for only catching it now. Patch 2 introduces a dependency on the xsk_socket__update_xskmap function which is available in: libbpf >= v0.3.0 and <= v0.6.0 libxdp > v1.2.0 The af_xdp.rst guide states we are compatible with libbpf (on it's own) <= v0.6.0. So users using libbpf < v0.3.0 will get an undefined reference warning for the xsk_socket__update_xskmap function. Is it possible to implement fallback functionality (or if that's not possible, bail out) if that function is not available? See how this is done for the xsk_socket__create_shared function in meson.build and compat.h. Thanks, Ciara </pre> </blockquote> Hi Ciara Yeah, no prob - I can re introduce the ``bpf_map_update_elem()`` call as a fall back. I will need to retest the permissions as I remember escalated permissions being required when issuing that call directly in the PMD which is why I moved it to using ``xsk_socket__update_xskmap()`` but let me retest and circle back with some changes. :) Looks like we are going to a v12 :) BR Maryam </body> </html>