Hi Daniel, On 09/17/15 09:13, Daniel Borkmann wrote:
Hmm, I don't really agree. With cls_bpf you have non-linear classifications as opposed to walking a chain of classifiers:
A chain of classifiers is a better description today (non-linear would be an appropriate description before cls_bpf ;->).
worst case, I have to walk through N classifiers just to find out that the last one matches that I need to drop - this doesn't scale at all.
The scaling reason with that posted example is not a strong one. You can get good performance with any classifier for that policy description. F.E with Alexei's second best classifier:->: tc filter add dev eth0 parent ffff: protocol arp prio 1 u32\ match all .. tc filter add dev eth0 parent ffff: protocol ip prio 1 u32\ ... But I do get the gist of your arguement otherwise and some short circuits are ok as you had earlier.
Given that we can make this decision right here, we can use this fact and have simple return codes provided as well.
I think it makes sense for the simple case. But you have every other opcode in there, not just basic accept/drop. I am worried this is leading towards an enclave of bpf do-everything. cheers, jamal -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
