On Thu, Jul 19, 2012 at 11:09:19PM -0700, Ben Pfaff wrote: > 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?
Yes, I think that sounds like a good approach. I was also not happy with how nx_pull_match() was getting out of control. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
