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