On 10/11/18 10:07 AM, Jamal Hadi Salim wrote: > On 2018-10-11 11:46 a.m., Sowmini Varadhan wrote: >> On (10/11/18 08:26), Stephen Hemminger wrote: >>> You can do the something like this already with BPF socket filters. >>> But writing BPF for multi-part messages is hard. >> >> Indeed. And I was just experimenting with this for ARP just last week. >> So to handle the caes of "ip neigh show a.b.c.d" without walking through >> the entire arp table and filtering in userspace, you could add a >> sk_filter() >> hook like this: >> > > If this could be done a lot earlier aka at xxx_fill_info() bpf would > be a very good answer.
IMO, bpf at the fill_info stage is not appropriate. > skb->sk (hence attached filter) should be available at that point. > Classical bpf per Sowmini's example maybe trickier. > Better - why dont we have an ebpf hook at this stage and then > we dont have to make changes to the kernel when someone adds > one more field to the filter? > > BTW: useful for events as well - not just dumps (as the name > fib_dump_filter suggests) you mean kernel notifications on internal events? 1. there is no user socket when notifications are created and the *_fill_info is invoked 2. notifications are global going to potentially many sockets. For these cases the existing sk_filter is appropriate.
