On 30.04, Daniel Borkmann wrote: > On 04/30/2015 02:30 AM, Patrick McHardy wrote: > >On 30.04, Daniel Borkmann wrote: > >>> > >>>I can also see there were also intentions to support userspace > >>>queueing at some point since TC_ACT_QUEUED has been there since the > >>>beginning. That should be possible at some point using this > >>>infrastructure (once there are no further concerns on the > >>>netif_receive_core_finish() patch as soon as gcc 4.9 and follow up > >>>versions keep inlining this new function). > >> > >>Wrt the other mail, just thinking out loud ... do you see a longer-term > >>possibility of further generalizing the gen hooks infrastructure, so that > >>actually classifier from tc could attach (disregarding the nf_* naming > >>scheme for now) ... > >> > >> `-> nf_hook_slow() > >> `-> [for each entry in hook list] <-- here as an entry > >> `-> nf_iterate() > >> `-> (*elemp)->hook() > >> > >>... as well? > > > >Jumping in there since I'm probably the one thinking the TC ingress > >abstraction is wrong the strongest - yes, it's an interesting idea. > >Unlike egress qdiscs, ingress only has a single classifier chain > >anyways, so there is no qdisc internal classification structure to > > Yes, exactly. > > >be observed. It should be possible to skip the ingress invocation > >for classification purposes completely and only use it to expose > >it to userspace for management purposes, while invoking the chain > >directly. > > That would also meet our goals to only have a single classifier > chain, eventually. ;) For TC, yes. What Pablo is trying to achieve (and I agree that it's worthwhile) is multiple things: * have people use TC ingress as before, obviously * have people use netfilter, if they prefer * have them combine both if for some unfortunate reason they require it Netfilter is based on hook chains. The cost when only using a single hook is minimal (as Pablo showed in his numbers), but even if only using TC and a single netfilter classifier chain, there has to be some relative ordering and the hooks provide this in a generic way. So I'm all in favour of reduing costs for single or for multi-hook cases, but it wouldn't be usable for us anymore when doing away with multiple hooks completely. One more point to consider is - this is generic infrastructure - the next person requiring a hook will not have to touch the ingress path at all. He can register with the hooks, having zero additional costs for people not using it. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
