On Tue, Apr 24, 2012 at 08:57:18AM -0700, Ben Pfaff wrote: > On Tue, Apr 24, 2012 at 10:02:25AM +0900, Simon Horman wrote: > > On Mon, Apr 23, 2012 at 08:34:45AM +0900, Simon Horman wrote: > > > On Fri, Apr 20, 2012 at 08:36:57AM -0700, Ben Pfaff wrote: > > > > On Fri, Apr 20, 2012 at 09:24:05AM +0900, Simon Horman wrote: > > > > > This may be used in a similar way to nxm_mf_fields > > > > > to handle parsing and serialisation of OXM TLVs. > > > > > > > > > > Signed-off-by: Simon Horman <ho...@verge.net.au> > > > > > > > > My own thought for how to do OXM was to just add a new 'oxm_header' > > > > member (and possibly 'oxm_name') to struct mf_field. Do you really > > > > think we need a whole new mostly redundant array? I hope not. > > > > > > Hi Ben, > > > > > > I hadn't thought about that, but it does seem like a reasonable approach. > > > I'll see about implementing it. > > > > One problem that I see arising here is that some fields are maskable in OXM > > but not in NXM and vice versa. > > In my opinion it doesn't matter. Exposing more maskability than > guaranteed by the spec is not a compatibility problem. That is, OVS > should support the more liberal maskability of the two standards. > > > + OXM_OF_ETH_SRC, OXM_OF_ARP_SHA, OXM_OF_ARP_THA, OXM_OF_IPV6_FLABEL > > - Maskable in OXM basic class but not in NXM > > We'll have to add maskability, and then we'll expose it through both > flow formats. Until we have it, let's just keep the current > maskability. > > Someone on the team here (Ansis?) is already working on > OXM_OF_IPV6_FLABEL maskability because one of our customers has a use > case. > > > + OXM_OF_TCP_SRC, OXM_OF_TCP_DST, OXM_OF_UDP_SRC, OXM_OF_UDP_DST > > - Maskable in NXM but not in OXM basic class > > It should be fine to make these maskable through OXM also.
Understood, that all sounds reasonable to me. I do have one other (minor) problem that I am facing which is the different widths of IN_PORT. 16 bits for NXM and 32 bits for OXM. Special casing this in the encoder isn't so bad, it basically encodes each field individually. However special-casing in the decoder would be rather ugly. One idea I have is to add OXM width fields (perhaps just bytes rather than bytes and bits). But at this point those fields would only be used for IN_PORT. Do you have any ideas? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
