On Fri, Jul 20, 2012 at 10:29:36AM +0900, Simon Horman wrote: > In the case of Open Flow 1.2, which is currently the only > time that OXM is be used, there is a 4 byte header before > the match which needs to be taken into account when calculating > the pad length. > > This is not entirely pretty, but it does seem to be correct. > > Signed-off-by: Simon Horman <ho...@verge.net.au>
Hmm. I don't see a problem with this per se, but the interface to nx_pull_match() is really starting to get terrible, with way too many parameters. Let's ignore that for a moment though, because I think I see a more important issue. Some of this code conflates the flow format (OXM vs. NXM) with its encapsulation (the simple format used in the Nicira extensions vs. the type/length header used in OF1.1+). Maybe there will never be a reason to encapsulate NXM inside the OF1.1+ type/length header (that'd be nice), but I think that in fact these are separate issues. (By the way, your nx_put_match() doesn't actually fill out the type/length header, it just zeroes it.) So, suppose that we separate them. On the "put" side, I think what we'd end up with a (static?) put_raw() function that just puts all the matches, and then two wrappers, an nxm_put_match() for NXM that just puts trailing zero-padding, and an oxm_put_match() that puts the type/length header and trailing zero-padding. On the "pull" side, something similar. Does that make any sense? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
