From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Daniel Borkmann <daniel@iogearbox.net>,
Cong Wang <xiyou.wangcong@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Jamal Hadi Salim <jhs@mojatatu.com>,
Vlad Buslov <vladbu@nvidia.com>, Jiri Pirko <jiri@resnulli.us>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Joe Stringer <joe@cilium.io>,
Quentin Monnet <quentin@isovalent.com>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Linux Kernel Network Developers <netdev@vger.kernel.org>
Subject: Re: [PATCH RFC bpf-next 0/7] Add bpf_link based TC-BPF API
Date: Wed, 16 Jun 2021 14:03:56 +0200 [thread overview]
Message-ID: <87a6nqqamr.fsf@toke.dk> (raw)
In-Reply-To: <15cd0a9c-95a1-9766-fca1-4bf9d09e4100@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> writes:
> On 6/15/21 1:54 PM, Toke Høiland-Jørgensen wrote:
>> Cong Wang <xiyou.wangcong@gmail.com> writes:
> [...]
>>>>> I offer two different views here:
>>>>>
>>>>> 1. If you view a TC filter as an instance as a netdev/qdisc/action, they
>>>>> are no different from this perspective. Maybe the fact that a TC filter
>>>>> resides in a qdisc makes a slight difference here, but like I mentioned, it
>>>>> actually makes sense to let TC filters be standalone, qdisc's just have to
>>>>> bind with them, like how we bind TC filters with standalone TC actions.
>>>>
>>>> You propose something different below IIUC, but I explained why I'm wary of
>>>> these unbound filters. They seem to add a step to classifier setup for no real
>>>> benefit to the user (except keeping track of one more object and cleaning it
>>>> up with the link when done).
>>>
>>> I am not even sure if unbound filters help your case at all, making
>>> them unbound merely changes their residence, not ownership.
>>> You are trying to pass the ownership from TC to bpf_link, which
>>> is what I am against.
>>
>> So what do you propose instead?
>>
>> bpf_link is solving a specific problem: ensuring automatic cleanup of
>> kernel resources held by a userspace application with a BPF component.
>> Not all applications work this way, but for the ones that do it's very
>> useful. But if the TC filter stays around after bpf_link detaches, that
>> kinda defeats the point of the automatic cleanup.
>>
>> So I don't really see any way around transferring ownership somehow.
>> Unless you have some other idea that I'm missing?
>
> Just to keep on brainstorming here, I wanted to bring back Alexei's earlier quote:
>
> > I think it makes sense to create these objects as part of establishing bpf_link.
> > ingress qdisc is a fake qdisc anyway.
> > If we could go back in time I would argue that its existence doesn't
> > need to be shown in iproute2. It's an object that serves no purpose
> > other than attaching filters to it. It doesn't do any queuing unlike
> > real qdiscs.
> > It's an artifact of old choices. Old doesn't mean good.
> > The kernel is full of such quirks and oddities. New api-s shouldn't
> > blindly follow them.
> > tc qdisc add dev eth0 clsact
> > is a useless command with nop effect.
>
> The whole bpf_link in this context feels somewhat awkward because both are two
> different worlds, one accessible via netlink with its own lifetime etc, the other
> one tied to fds and bpf syscall. Back in the days we did the cls_bpf integration
> since it felt the most natural at that time and it had support for both the ingress
> and egress side, along with the direct action support which was added later to have
> a proper fast path for BPF. One thing that I personally never liked is that later
> on tc sadly became a complex, quirky dumping ground for all the nic hw offloads (I
> guess mainly driven from ovs side) for which I have a hard time convincing myself
> that this is used at scale in production. Stuff like af699626ee26 just to pick one
> which annoyingly also adds to the fast path given distros will just compile in most
> of these things (like NET_TC_SKB_EXT)... what if such bpf_link object is not tied
> at all to cls_bpf or cls_act qdisc, and instead would implement the tcf_classify_
> {egress,ingress}() as-is in that sense, similar like the bpf_lsm hooks. Meaning,
> you could run existing tc BPF prog without any modifications and without additional
> extra overhead (no need to walk the clsact qdisc and then again into the cls_bpf
> one). These tc BPF programs would be managed only from bpf() via tc bpf_link api,
> and are otherwise not bothering to classic tc command (though they could be dumped
> there as well for sake of visibility, though bpftool would be fitting too). However,
> if there is something attached from classic tc side, it would also go into the old
> style tcf_classify_ingress() implementation and walk whatever is there so that nothing
> existing breaks (same as when no bpf_link would be present so that there is no extra
> overhead). This would also allow for a migration path of multi prog from cls_bpf to
> this new implementation. Details still tbd, but I would much rather like such an
> approach than the current discussed one, and it would also fit better given we don't
> run into this current mismatch of both worlds.
So this would entail adding a separate list of BPF programs and run
through those at the start of sch_handle_{egress,ingress}() I suppose?
And that list of filters would only contain bpf_link-attached BPF
programs, sorted by priority like TC filters? And return codes of
TC_ACT_OK or TC_ACT_RECLASSIFY would continue through to
tcf_classify_{egress,ingress}()?
I suppose that could work; we could even stick the second filter list in
struct mini_Qdisc and have clsact and bpf_link cooperate on managing
that, no? That way it would also be easy to dump the BPF filters via
netlink: I do think that will be the least surprising thing to do (so
people can at least see there's something there with existing tools).
The overhead would be a single extra branch when only one of clsact or
bpf_link is in use (to check if the other list of filters is set);
that's probably acceptable at this level...
-Toke
next prev parent reply other threads:[~2021-06-16 12:04 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-28 19:59 [PATCH RFC bpf-next 0/7] Add bpf_link based TC-BPF API Kumar Kartikeya Dwivedi
2021-05-28 19:59 ` [PATCH RFC bpf-next 1/7] net: sched: refactor cls_bpf creation code Kumar Kartikeya Dwivedi
2021-05-28 19:59 ` [PATCH RFC bpf-next 2/7] bpf: export bpf_link functions for modules Kumar Kartikeya Dwivedi
2021-05-28 19:59 ` [PATCH RFC bpf-next 3/7] net: sched: add bpf_link API for bpf classifier Kumar Kartikeya Dwivedi
2021-06-02 20:56 ` Andrii Nakryiko
2021-05-28 19:59 ` [PATCH RFC bpf-next 4/7] net: sched: add lightweight update path for cls_bpf Kumar Kartikeya Dwivedi
2021-05-28 19:59 ` [PATCH RFC bpf-next 5/7] tools: bpf.h: sync with kernel sources Kumar Kartikeya Dwivedi
2021-05-28 19:59 ` [PATCH RFC bpf-next 6/7] libbpf: add bpf_link based TC-BPF management API Kumar Kartikeya Dwivedi
2021-06-02 21:03 ` Andrii Nakryiko
2021-05-28 19:59 ` [PATCH RFC bpf-next 7/7] libbpf: add selftest for " Kumar Kartikeya Dwivedi
2021-06-02 21:09 ` [PATCH RFC bpf-next 0/7] Add bpf_link based TC-BPF API Andrii Nakryiko
2021-06-02 21:45 ` Kumar Kartikeya Dwivedi
2021-06-02 23:50 ` Alexei Starovoitov
2021-06-04 6:43 ` Kumar Kartikeya Dwivedi
2021-06-06 23:37 ` Cong Wang
2021-06-07 3:37 ` Kumar Kartikeya Dwivedi
2021-06-07 5:18 ` Cong Wang
2021-06-07 6:07 ` Kumar Kartikeya Dwivedi
2021-06-08 2:00 ` Cong Wang
2021-06-08 7:19 ` Kumar Kartikeya Dwivedi
2021-06-08 15:39 ` Alexei Starovoitov
2021-06-11 2:10 ` Cong Wang
2021-06-11 2:00 ` Cong Wang
2021-06-13 2:53 ` Kumar Kartikeya Dwivedi
2021-06-13 20:27 ` Jamal Hadi Salim
2021-06-13 20:34 ` Kumar Kartikeya Dwivedi
2021-06-13 21:10 ` Jamal Hadi Salim
2021-06-14 13:03 ` Marcelo Ricardo Leitner
2021-06-15 23:07 ` Daniel Borkmann
2021-06-16 14:40 ` Jamal Hadi Salim
2021-06-16 15:32 ` Kumar Kartikeya Dwivedi
2021-06-16 16:00 ` Daniel Borkmann
2021-06-18 11:40 ` Jamal Hadi Salim
2021-06-18 14:38 ` Alexei Starovoitov
2021-06-18 14:50 ` Jamal Hadi Salim
2021-06-18 16:23 ` Alexei Starovoitov
2021-06-18 16:41 ` Jamal Hadi Salim
2021-06-18 22:42 ` Daniel Borkmann
2021-06-21 13:55 ` Jamal Hadi Salim
2021-06-15 4:33 ` Cong Wang
2021-06-15 11:54 ` Toke Høiland-Jørgensen
2021-06-15 23:44 ` Daniel Borkmann
2021-06-16 12:03 ` Toke Høiland-Jørgensen [this message]
2021-06-16 15:33 ` Jamal Hadi Salim
2021-06-13 3:08 ` Kumar Kartikeya Dwivedi
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=87a6nqqamr.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=joe@cilium.io \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=memxor@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=quentin@isovalent.com \
--cc=songliubraving@fb.com \
--cc=vladbu@nvidia.com \
--cc=xiyou.wangcong@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).