Introduce helper to make is easier to test two struct variations
with the same invalid btf_id struct location.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
It is a bad habit to rely on process exit to free memory.
Add proper memory free operations.
Using checker command:
valgrind --leak-check=yes ./btf_unit_test
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Now that lib side of xsk_btf__init_xdp_hint check for a valid
btf_id variable, then users of the call doesn't need to check
for the existance of a btf_id member.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
If there were more transmit slots, then we umem free the
packet, but we continued sending it anyhow.
The places tx_pkt() is currently used this never happened.
Still fix the bug.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
I hope there exist a better API for determining when AF_XDP
is ready for transmitting packets.
This workaround keeps trying to send a single packet, and
check return value seen from sendto() syscall, until it
doesn't return an error.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Give a print WARN if code/AF_XDP somehow have MORE packets to
complete from CQ than our counter for xsk->outstanding_tx packets.
This should not happen, but currently hunting for a TX issue.
The code (below) reset xsk->outstanding_tx, which were introduced
via a discussion on xdp-tutorial:
https://github.com/xdp-project/xdp-tutorial/issues/180
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
This is done to easier visually see the time difference
when debug printing the timespec's (via print_timespec).
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Measurements show that on test systems, clock_nanosleep fairly
consistently wakeup later (or after) the requested sleep time.
It is fairly trivial to simply adjust the sleep/wakeup time
with the measure inaccuracy of clock_nanosleep, and "ask"
clock_nanosleep to wakeup a bit earlier.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Calling tx_pkt() before the link is ready, result in no packets
transmitted, but xsk_ring_prod__reserve() still succeeds.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
The apply_setsockopt() was taken from samples/bpf/xdpsock_user.c
Testing with --zero-copy this unfortunately doesn't solve
the issue of 8 packets bulks when requesting 4.
Notice this test was with driver igc and chip i225.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Measurements on a receiver shows that TX doesn't happen immediately.
Even when calling sendto() for doing TX kick.
Added bind flag XDP_USE_NEED_WAKEUP, but this didn't help.
TX burst 4 packets, but in --zero-copy mode we often observe
8 packets arriving in a burst.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
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>
