[ovs-dev] [PATCH 3/3] [RFC] Add oxm_mf_fields

[Ben Pfaff]

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 <horms at 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.