mbox series

[bpf-next,v2,0/6] AF_XDP Packet Drop Tracing

Message ID 20210126075239.25378-1-ciara.loftus@intel.com (mailing list archive)
Headers show
Series AF_XDP Packet Drop Tracing | expand

Message

Ciara Loftus Jan. 26, 2021, 7:52 a.m. UTC
This series introduces tracing infrastructure for AF_XDP sockets (xsks).
A trace event 'xsk_packet_drop' is created which can be enabled by toggling

/sys/kernel/debug/tracing/events/xsk/xsk_packet_drop/enable

When enabled and packets are dropped in the kernel, traces are generated
which describe the reason for the packet drop as well as the netdev and
qid information of the xsk which encountered the drop.

Example traces:

507.588563: xsk_packet_drop: netdev: eth0 qid 0 reason: rxq full
507.588567: xsk_packet_drop: netdev: eth0 qid 0 reason: packet too big
507.588568: xsk_packet_drop: netdev: eth0 qid 0 reason: fq empty

The event can also be monitored using perf:

perf stat -a -e xsk:xsk_packet_drop

Three selftests are added which each ensure the appropriate traces are
generated for the following scenarios:
* rx queue full
* packet too big
* fill queue empty

v1->v2:
* Rebase on top of Björn's cleanup series.
* Fixed packet count for trace tests which don't need EOT frame.

This series applies on commit 190d1c921ad0862da14807e1670f54020f48e889

Ciara Loftus (6):
  xsk: add tracepoints for packet drops
  selftests/bpf: restructure setting the packet count
  selftests/bpf: add framework for xsk selftests
  selftests/bpf: XSK_TRACE_DROP_RXQ_FULL test
  selftests/bpf: XSK_TRACE_DROP_PKT_TOO_BIG test
  selftests/bpf: XSK_TRACE_DROP_FQ_EMPTY test

 MAINTAINERS                                |   1 +
 include/linux/bpf_trace.h                  |   1 +
 include/trace/events/xsk.h                 |  45 +++++
 include/uapi/linux/if_xdp.h                |   8 +
 kernel/bpf/core.c                          |   1 +
 net/xdp/xsk.c                              |   5 +
 net/xdp/xsk_buff_pool.c                    |   8 +-
 tools/include/uapi/linux/if_xdp.h          |   8 +
 tools/testing/selftests/bpf/test_xsk.sh    |  90 +++++++++-
 tools/testing/selftests/bpf/xdpxceiver.c   | 192 +++++++++++++++++++--
 tools/testing/selftests/bpf/xdpxceiver.h   |  10 ++
 tools/testing/selftests/bpf/xsk_prereqs.sh |   3 +-
 12 files changed, 348 insertions(+), 24 deletions(-)
 create mode 100644 include/trace/events/xsk.h

Comments

Toke Høiland-Jørgensen Jan. 26, 2021, 8:45 a.m. UTC | #1
Ciara Loftus <ciara.loftus@intel.com> writes:

> This series introduces tracing infrastructure for AF_XDP sockets (xsks).
> A trace event 'xsk_packet_drop' is created which can be enabled by toggling
>
> /sys/kernel/debug/tracing/events/xsk/xsk_packet_drop/enable
>
> When enabled and packets are dropped in the kernel, traces are generated
> which describe the reason for the packet drop as well as the netdev and
> qid information of the xsk which encountered the drop.
>
> Example traces:
>
> 507.588563: xsk_packet_drop: netdev: eth0 qid 0 reason: rxq full
> 507.588567: xsk_packet_drop: netdev: eth0 qid 0 reason: packet too big
> 507.588568: xsk_packet_drop: netdev: eth0 qid 0 reason: fq empty
>
> The event can also be monitored using perf:
>
> perf stat -a -e xsk:xsk_packet_drop

Would it make sense to also hook this up to drop_monitor?

-Toke
Ciara Loftus Jan. 27, 2021, 10:17 a.m. UTC | #2
> 
> Ciara Loftus <ciara.loftus@intel.com> writes:
> 
> > This series introduces tracing infrastructure for AF_XDP sockets (xsks).
> > A trace event 'xsk_packet_drop' is created which can be enabled by
> toggling
> >
> > /sys/kernel/debug/tracing/events/xsk/xsk_packet_drop/enable
> >
> > When enabled and packets are dropped in the kernel, traces are generated
> > which describe the reason for the packet drop as well as the netdev and
> > qid information of the xsk which encountered the drop.
> >
> > Example traces:
> >
> > 507.588563: xsk_packet_drop: netdev: eth0 qid 0 reason: rxq full
> > 507.588567: xsk_packet_drop: netdev: eth0 qid 0 reason: packet too big
> > 507.588568: xsk_packet_drop: netdev: eth0 qid 0 reason: fq empty
> >
> > The event can also be monitored using perf:
> >
> > perf stat -a -e xsk:xsk_packet_drop
> 
> Would it make sense to also hook this up to drop_monitor?
> 
> -Toke

Thanks for bring that to my attention Toke. I think it makes sense.
I put together a quick prototype and it looks like a good fit.
Neil what do you think?
Perhaps as a follow up patch to the series in question however?

Ciara