[adding Shahbaz] On Tue, Mar 29, 2016 at 05:43:55PM -0700, Jesse Gross wrote: > There really isn't a way to avoid extracting the header fields in > software - I don't think that any NIC short of an NPU or other > programmable hardware has the capability to match on all of the fields > that OVS supports. Certainly, the UDP source port used by VXLAN and > other tunnel protocols does not contain all of the information and, > worse, it's controlled by a remote system. We can't trust the > information contained in it without further verification because OVS > flow rules are often used for security checks. I realize that in many > cases this will appear to work because for a flow represented by a > 5-tuple many of the other fields will be the same. However, we can't > just make this assumption. > > One possible exception to this rule is if we did an analysis on the > flows that are actually being used by OVS and only tried to extract > those fields. This is a pure software optimization that might have > similar effects to what you are observing here. This most likely makes > the most sense in the context of a BPF based datapath where the flow > extractor can be dynamically generated and compiled.
This is probably going to be a side effect of the P4 support for Open vSwitch that Shahbaz is working on. The first iteration will probably have the fields fixed at OVS build time, though. Later iterations would ideally use eBPF for the kernel and possibly a direct JIT for DPDK to enable fields to be reconfigured at OVS runtime. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
