Re: [PATCH RFC bpf-next 0/7] Add bpf_link based TC-BPF API

On Fri, May 28, 2021 at 1:00 PM Kumar Kartikeya Dwivedi
[off-list ref] wrote:

This is the first RFC version.

This adds a bpf_link path to create TC filters tied to cls_bpf classifier, and
introduces fd based ownership for such TC filters. Netlink cannot delete or
replace such filters, but the bpf_link is severed on indirect destruction of the
filter (backing qdisc being deleted, or chain being flushed, etc.). To ensure
that filters remain attached beyond process lifetime, the usual bpf_link fd
pinning approach can be used.

I have some troubles understanding this. So... why TC filter is so special
here that it deserves such a special treatment?

The reason why I ask is that none of other bpf links actually create any
object, they merely attach bpf program to an existing object. For example,
netns bpf_link does not create an netns, cgroup bpf_link does not create
a cgroup either. So, why TC filter is so lucky to be the first one requires
creating an object?

Is it because there is no fd associated with any TC object?  Or what?
TC object, like all other netlink stuffs, is not fs based, hence does not
have an fd. Or maybe you don't need an fd at all? Since at least xdp
bpf_link is associated with a netdev which does not have an fd either.

The individual patches contain more details and comments, but the overall kernel
API and libbpf helper mirrors the semantics of the netlink based TC-BPF API
merged recently. This means that we start by always setting direct action mode,
protocol to ETH_P_ALL, chain_index as 0, etc. If there is a need for more
options in the future, they can be easily exposed through the bpf_link API in
the future.

As you already see, this fits really oddly into TC infrastructure, because
TC qdisc/filter/action are a whole subsystem, here you are trying to punch
a hole in the middle. ;) This usually indicates that we are going in a wrong
direction, maybe your case is an exception, but I can't find anything to justify
it in your cover letter.

Even if you really want to go down this path (I still double), you probably
want to explore whether there is any generic way to associate a TC object
with an fd, because we have TC bpf action and we will have TC bpf qdisc
too, I don't see any bpf_cls is more special than them.

Thanks.