From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>,
"Björn Töpel" <bjorn.topel@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Netdev <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Ido Schimmel <idosch@idosch.org>
Subject: Re: [RFC PATCH bpf-next] xdp: Add tracepoint on XDP program return
Date: Tue, 17 Dec 2019 09:52:02 +0100 [thread overview]
Message-ID: <87h81z8hcd.fsf@toke.dk> (raw)
In-Reply-To: <20191217005944.s3mayy473ldlnldl@ast-mbp.dhcp.thefacebook.com>
Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
> On Mon, Dec 16, 2019 at 07:17:59PM +0100, Björn Töpel wrote:
>> On Mon, 16 Dec 2019 at 16:28, Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>> >
>> > This adds a new tracepoint, xdp_prog_return, which is triggered at every
>> > XDP program return. This was first discussed back in August[0] as a way to
>> > hook XDP into the kernel drop_monitor framework, to have a one-stop place
>> > to find all packet drops in the system.
>> >
>> > Because trace/events/xdp.h includes filter.h, some ifdef guarding is needed
>> > to be able to use the tracepoint from bpf_prog_run_xdp(). If anyone has any
>> > ideas for how to improve on this, please to speak up. Sending this RFC
>> > because of this issue, and to get some feedback from Ido on whether this
>> > tracepoint has enough data for drop_monitor usage.
>> >
>>
>> I get that it would be useful, but can it be solved with BPF tracing
>> (i.e. tracing BPF with BPF)? It would be neat not adding another
>> tracepoint in the fast-path...
>
> That was my question as well.
> Here is an example from Eelco:
> https://lore.kernel.org/bpf/78D7857B-82E4-42BC-85E1-E3D7C97BF840@redhat.com/
> BPF_TRACE_2("fexit/xdp_prog_simple", trace_on_exit,
> struct xdp_buff*, xdp, int, ret)
> {
> bpf_debug("fexit: [ifindex = %u, queue = %u, ret = %d]\n",
> xdp->rxq->dev->ifindex, xdp->rxq->queue_index, ret);
>
> return 0;
> }
> 'ret' is return code from xdp program.
> Such approach is per xdp program, but cheaper when not enabled
> and faster when it's triggering comparing to static tracepoint.
> Anything missing there that you'd like to see?
For userspace, sure, the fentry/fexit stuff is fine. The main use case
for this new tracepoint is to hook into the (in-kernel) drop monitor.
Dunno if that can be convinced to hook into the BPF tracing
infrastructure instead of tracepoints. Ido, WDYT?
-Toke
next prev parent reply other threads:[~2019-12-17 8:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-16 15:27 [RFC PATCH bpf-next] xdp: Add tracepoint on XDP program return Toke Høiland-Jørgensen
2019-12-16 18:17 ` Björn Töpel
2019-12-17 0:59 ` Alexei Starovoitov
2019-12-17 8:52 ` Toke Høiland-Jørgensen [this message]
2019-12-23 9:25 ` Ido Schimmel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h81z8hcd.fsf@toke.dk \
--to=toke@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=bjorn.topel@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=idosch@idosch.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.