On 04/29/2015 08:53 PM, Pablo Neira Ayuso wrote:
Port qdisc ingress on top of the Netfilter ingress allows us to detach the
qdisc ingress filtering code from the core, so now it resides where it really
belongs.
Hm, but that means, in case you have a tc ingress qdisc attached
with one single (ideal) or more (less ideal) classifier/actions,
the path we _now_ have to traverse just to a single tc classifier
invocation is, if I spot this correctly, f.e.:
__netif_receive_skb_core()
`-> nf_hook_ingress()
`-> nf_hook_do_ingress()
`-> nf_hook_slow()
`-> [for each entry in hook list]
`-> nf_iterate()
`-> (*elemp)->hook()
`-> handle_ing()
`-> ing_filter()
`-> qdisc_enqueue_root()
`-> sch->enqueue()
`-> ingress_enqueue()
`-> tc_classify()
`-> tc_classify_compat()
`-> [for each attached classifier]
`-> tp->classify()
`-> f.e. cls_bpf_classify()
`-> [for each classifier from plist]
`-> BPF_PROG_RUN()
What was actually mentioned in the other thread where we'd like to
see a more lightweight ingress qdisc is to cut that down tremendously
to increase pps rate, as provided, that we would be able to process
a path roughly like:
__netif_receive_skb_core()
`-> tc_classify()
`-> tc_classify_compat()
`-> [for each attached classifier]
`-> tp->classify()
`-> f.e. cls_bpf_classify()
`-> [for each classifier from plist]
`-> BPF_PROG_RUN()
Therefore, I think it would be better to not wrap that ingress qdisc
part of the patch set into even more layers. What do you think?
Thanks,
Daniel
--
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
