On Thu, Jul 17, 2014 at 3:53 PM, Joe Stringer <joestrin...@nicira.com> wrote: > On 18 July 2014 05:19, Ben Pfaff <b...@nicira.com> wrote: >> - If the userspace flow key includes more fields than the >> > kernel's, for example if userspace decoded an IPv6 header but >> > the kernel stopped at the Ethernet type, then userspace can >> > forward the packet manually, without setting up a flow in the >> > kernel. This case is bad for performance because every packet >> > that the kernel considers part of the flow must go to userspace, >> > but the forwarding behavior is correct. (If userspace can >> > determine that the values of the extra fields would not affect >> > forwarding behavior, then it could set up a flow anyway.) >> > >> > Looking further in the README, the patch doesn't handle this case >> > appropriately. If the interpretation of that last part of the README is >> > valid, then we could look at ways to fix this. For instance, after >> copying >> > the key, do a pass over it looking for attributes we don't understand, >> and >> > remove them. Alternatively we could skip caching in this case. >> > >> > >> > Does this address your concerns adequately? >> >> Not entirely. It still means that kernel-generated and >> userspace-generated flow keys could, for example, order the fields >> differently, or accidentally fill some ignored padding fields with >> different bytes. > > > Hmm. The README says that field ordering is not significant. I'm not sure > about the latter concern, but it sounds like there are many aspects to this > which I haven't considered yet.
It's true, the field ordering is not significant if you understand all of the fields. The concern is that userspace may want to keep track of flows even if it doesn't understand all of the fields (for example, it can determine that the kernel provides information about some additional fields that userspace doesn't care about and just mask those out). In this case, to keep track of what is in the kernel, userspace would likely do a hash and comparison over the byte stream of the key. In that situation, even if reordering wouldn't cause the meaning to change, it would cause the comparison to fail. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
