The assumption was that our simple memory allocator for umem
frames return an addr that point to the start of the frame.
When a frame addr is freed/returned via mem_free_umem_frame()
this frame addr doesn't necessary point to the start of the
frame. Often this is not the case. As the kernel RX process
will add some headroom. Our userspace TX process can also choose
to add headroom, resulting in frames returned in Completion Queue
will also have this headroom offset in the addr.
Fix by removing headroom offset when freeing/returning the
frame addr in mem_free_umem_frame().
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
The latency or time-delay between XDP and AF_XDP depend highly
on whether the XDP and AF_XDP runs on same CPU or remote CPU.
Extend xdp_hints_rx_time, without worrying about the layout
as BTF will adjust, so we can determine case of same CPU or
remote CPU.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
The stats poll doesn't take into account multiple XSK sockets.
Simply disable until there is time to fix it.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Now that program process all queues it is relevant to know
what queue_id received the packet.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Cannot share/associate the FQ (Fill Queue) and CQ (Completion Q) with
umem container (xsk_umem_info). This is the reason current program
cannot handle packets for each queue ID.
As described in [1] we need more FQ and CQ ring pairs, a pair per for each
unique netdev and queue IP tuple.
Thus, add FQ and CQ for each queue id in struct xsk_socket_info.
[1] https://www.kernel.org/doc/html/latest/networking/af_xdp.html
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
It is confusing to name the option what will wait for packets
on the file descriptor, for --poll, just because the function
call have this name. It confusing as AF_XDP users often want
to busy-poll for packets (for max performance reasons).
Name the new option --wakeup instead of --wait as the effect
of waiting for the FD is that the kernel needs to wakeup
the userspace process.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
The macros XSK_BTF_READ_xxx doesn't handle or report on errors
if the input or field were wrong, which is not uncommon for macros.
The bad behavior is that the macro continue to dereference the
pointer even-when xsk_btf__read_xxx() functions returns an error.
This often leads to crashing the application.
Change macro to only dereference when no errors were reported.
Side-note: The compiler warnings will detect if API user didn't
init the 'dest' value with a default value. As the effect of
the change is that the 'dest' value will not be touch, and thus
contain the value before the macro was used.
Example:
warning: ‘mark’ may be used uninitialized in this function
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>