On Thu, Oct 11, 2018 at 9:16 AM David Ahern <dsah...@gmail.com> wrote: > > 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.
3. All networking subsystems already have this type of netlink attribute filtering that apps rely on. This series just makes it consistent for route dumps. Apps use such mechanism already when requesting dumps. Like everywhere else, BPF hook can be an alternate parallel mechanism.
