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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
