On Wed, Jun 8, 2016 at 2:30 PM, Daniel Borkmann <dan...@iogearbox.net> wrote: > On 06/06/2016 09:52 PM, Cong Wang wrote: >> >> On Mon, Jun 6, 2016 at 12:25 PM, Daniel Borkmann <dan...@iogearbox.net> >> wrote: > > [...] >> >> This is fundamental for libnl to update caches. >> >> I don't understand why it should be separated, since notification is >> not a feature, we already have notifications in other paths. >> >>> Looking into this, I would probably make this a single notification that >>> denotes this 'wild-card' removal for that parent instead of calling >>> tfilter_notify() for each filter separately (which allocs skb, dumps it, >>> etc), qdisc del doesn't loop through it either, so probably fine this >>> way. >> >> >> Makes sense. > > > I've been playing around with both options and am actually currently > leaning towards the tfilter_notify() for each proto for the reason > that user space tc monitors can simply stay as is. F.e., if someone > keeps an older libnl binary that wouldn't understand such a wildcard > message, then elements in libnl cache won't receive updates since the > meta data won't match on them (average case, there probably are only > one up to a handful of classifiers per parent) ... hm, different topic > but still wondering whether libnl relying on such messages is a good > idea in general since under stress tfilter_notify() can also fail and > user space won't get the updates (except for queries with RTM_GETTFILTER).
Don't worry about any failure in tfilter_notify(), we call it in non-wildcard removal too. Your current patch looks good to me. Thanks!
