From: He Kuang <hekuang@huawei.com>
To: Alexei Starovoitov <ast@plumgrid.com>
Cc: <wangnan0@huawei.com>, LKML <linux-kernel@vger.kernel.org>,
"daniel@iogearbox.net >> Daniel Borkmann" <daniel@iogearbox.net>
Subject: Re: [RFC] bpf: Suggestion on bpf syscall interface
Date: Mon, 30 Mar 2015 11:13:51 +0800 [thread overview]
Message-ID: <5518BF6F.4080406@huawei.com> (raw)
In-Reply-To: <5516E32B.6030502@plumgrid.com>
On 2015/3/29 1:21, Alexei Starovoitov wrote:
> On 3/28/15 4:36 AM, He Kuang wrote:
>> Hi, Alexei
>>
>> In our end-end IO module project, we use bpf maps to record
>> configurations. According to current bpf syscall interface, we
>> should specify map_fd to lookup/update bpf maps, so we are
>> restricted to do config in the same user program.
>
> you can pass map_fd and prog_fd from one process to another via normal
> scm_rights mechanism.
In our current use case, we add a bpf probe point in sys_write()
as the entry of IO procedure, this bpf point will return true on
some conditions, and then trigger bpf chain on IO path, for
example:
SEC("kprobe/sys_write")
int NODE_sys_write(struct pt_regs *ctx) {
...
struct parameters *param = bpf_map_lookup_elem(¶meters_map,
&index);
if(param->num_samples % param->sample_rate !=0)
return 0;
...
/* extract characters from this sampled point, fill it to another
map */
bpf_map_update_elem(&TRIGGER_mpage_submit_page_HASH,
(void**)__b__buf, &value, BPF_ANY);
return 1;
...
SEC("kprobe/mpage_submit_page")
int NODE_mpage_submit_page(struct pt_regs *ctx) {
...
/* lookup filter table */
value = (struct
table_value*)bpf_map_lookup_elem(&TRIGGER_mpage_submit_page_HASH,
(void**)__b__buf);
if (!value) return 0;
...
By using current bpf syscalls, we should keep the program which
attaches bpf programs running background, use it or some other
processes communicate with it to adjust maps parameters, like
sample rate for sys_write.
What we hope is to use bpf maps/progs like kernel-modules or
kprobes, one process inserts them to kernel, then they detactch
from that process, and allow us to configure them with sysfs. For
example:
$ perf probe --add='sys_write'
$ perf record -e probe:sys_open -aR sleep 1
In current implementation, we have to use a large and relative
heavy daemon to deal with loading, configuration, adjusting and
unloading works together.
Thanks.
>
>> My suggestion is to export this kind of operations to sysfs, so
>> we can load&attach bpf progs and config it seperately. We
>> implement this feature in our demo project. What's your opinion
>> on this?
>
> Eventually we may use single sysfs file for lsmod-like listings, but I
> definitely don't want to create parallel interface to maps via sysfs.
> It's way too expensive and not really suitable for binary key/values.
>
>
>
>
next prev parent reply other threads:[~2015-03-30 3:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-28 11:36 [RFC] bpf: Suggestion on bpf syscall interface He Kuang
2015-03-28 17:21 ` Alexei Starovoitov
2015-03-28 22:16 ` Daniel Borkmann
2015-03-30 3:13 ` He Kuang [this message]
2015-03-31 3:23 ` Alexei Starovoitov
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=5518BF6F.4080406@huawei.com \
--to=hekuang@huawei.com \
--cc=ast@plumgrid.com \
--cc=daniel@iogearbox.net \
--cc=linux-kernel@vger.kernel.org \
--cc=wangnan0@huawei.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