Cong Wang <xiyou.wangcong@xxxxxxxxx> 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? -Toke
