Add cleanup code to load_attach_bpfprogs function, so it should always
unpin tc program, and additionally detach the tc and xdp programs in
case of any failure.
Also unpin tc program directly after attaching it (rather than on
program shutdown), so that multiple instances of pping can be run
simultaneously (on different interfaces).
Finally, rename some of the functions for attaching/detaching tc
programs to be more consistent with the xdp ones.
Note: Still need to keep a copy of most of the cleanup code in main as
well, as the tc and xdp programs also need to be detached on program
shutdown or if later functions fail.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
Newer libbpf uses constants from the newer kernel header file, so
compilation breaks unless we have the newest version of the kernel header.
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
The bpf_program__next() helper was deprecated in favour of
bpf_object__next_program(), so switch to that.
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Update the libbpf submodule to the latest version, and update the configure
script so we check for the newer bpf_object__next_program() helper (to fix
deprecation warnings).
Signed-off-by: Toke Høiland-Jørgensen <toke@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>
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>
