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. When reading the spec I made the following notes. + 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 + 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 Do you think an oxm_maskable field is in order? > > I'd be inclined to omit the new field types introduced by OF1.1/OF1.2, > > such as MPLS, until we have an implementation. > > Sure, that also sounds reasonable. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
