From: David Vernet <void@manifault.com>
To: Hao Luo <haoluo@google.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org, john.fastabend@gmail.com,
martin.lau@linux.dev, song@kernel.org, yhs@fb.com,
kpsingh@kernel.org, sdf@google.com, jolsa@kernel.org,
tj@kernel.org, joannelkoong@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] bpf: Add user-space-publisher ringbuffer map type
Date: Tue, 9 Aug 2022 20:15:10 -0500 [thread overview]
Message-ID: <20220810011510.c3chrli27e6ebftt@maniforge> (raw)
In-Reply-To: <CA+khW7iuENZHvbyWUkq1T1ieV9Yz+MJyRs=7Kd6N59kPTjz7Rg@mail.gmail.com>
Hi Hao,
On Mon, Aug 08, 2022 at 11:57:53AM -0700, Hao Luo wrote:
> > Note that one thing that is not included in this patch-set is the ability
> > to kick the kernel from user-space to have it drain messages. The selftests
> > included in this patch-set currently just use progs with syscall hooks to
> > "kick" the kernel and have it drain samples from a user-producer
> > ringbuffer, but being able to kick the kernel using some other mechanism
> > that doesn't rely on such hooks would be very useful as well. I'm planning
> > on adding this in a future patch-set.
> >
>
> This could be done using iters. Basically, you can perform draining in
> bpf_iter programs and export iter links as bpffs files. Then to kick
> the kernel, you simply just read() the file.
Thanks for pointing this out. I agree that iters could be used this way to
kick the kernel, and perhaps that would be a sufficient solution. My
thinking, however, was that it would be useful to provide some APIs that
are a bit more ergonomic, and specifically meant to enable kicking
arbitrary "pre-attached" callbacks in a BPF prog, possibly along with some
payload from userspace.
Iters allow userspace to kick the kernel, but IMO they're meant to enable
data extraction from the kernel, and dumping kernel data into user-space.
What I'm proposing is a more generalizable way of driving logic in the
kernel from user-space.
Does that make sense? Looking forward to hearing your thoughts.
Thanks,
David
next prev parent reply other threads:[~2022-08-10 1:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-08 15:52 [PATCH 0/5] bpf: Add user-space-publisher ringbuffer map type David Vernet
2022-08-08 18:57 ` Hao Luo
2022-08-10 1:15 ` David Vernet [this message]
2022-08-15 21:13 ` Hao Luo
2022-08-16 15:09 ` David Vernet
2022-08-16 17:01 ` Hao Luo
2022-08-16 21:39 ` David Vernet
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=20220810011510.c3chrli27e6ebftt@maniforge \
--to=void@manifault.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=joannelkoong@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=tj@kernel.org \
--cc=yhs@fb.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox