[ovs-dev] [PATCH 02/24] nx-match: Do not include NXM only matches when putting an OMX match
Simon Horman
horms at verge.net.au
Wed Jul 25 02:33:31 UTC 2012
On Tue, Jul 24, 2012 at 07:22:51PM -0700, Ben Pfaff wrote:
> On Wed, Jul 25, 2012 at 09:40:07AM +0900, Simon Horman wrote:
> > On Tue, Jul 24, 2012 at 05:20:20PM -0700, Ben Pfaff wrote:
> > > On Wed, Jul 25, 2012 at 08:57:08AM +0900, Simon Horman wrote:
> > > > On Tue, Jul 24, 2012 at 11:53:49AM -0700, Ben Pfaff wrote:
> > > > > On Mon, Jul 23, 2012 at 03:16:31PM +0900, Simon Horman wrote:
> > > > > > Suggested by Isaku Yamahata
> > > > > >
> > > > > > Cc: Isaku Yamahata <yamahata at valinux.co.jp?
> > > > > > Signed-off-by: Simon Horman <horms at verge.net.au>
> > > > >
> > > > > I don't think I agree with this idea. There is no incompatibility
> > > > > between OXM and NXM and in fact the NXM classes are reserved
> > > > > explicitly in OF1.2 for Nicira use. What's the benefit to omitting
> > > > > important details from a flow?
> > > >
> > > > Is the implication of this that a parser should just ignore fields that it
> > > > doesn't understand?
> > > >
> > > > The reason that this came up was that I was testing OVS using Ryu and
> > > > Ryu does strict parsing, complaining bitterly if a field which it
> > > > doesn't understand is present.
> > >
> > > No, I don't think a parser should ignore fields that it doesn't
> > > understand[*], and I think (without knowing anything about Ryu) that
> > > Ryu is probably doing the right thing. Here are the two possibilities
> > > and my opinion on their implications:
> > >
> > > - OVS only sends OXM-defined fields in OXM contexts. Suppose
> > > a controller is initializing itself by dumping a flow table
> > > and comparing against what it thinks should be there. If an
> > > NXM controller was running before, then the new controller
> > > could see duplicate flows (that differ only in match fields
> > > it doesn't see), and it could see flows that it thinks have
> > > match fields it understands but really have hidden match
> > > fields that it doesn't. If it tries to delete or change any
> > > of those flows, it can easily make the problem worse,
> > > because it could create more "duplicates" or not match
> > > anything for deletion because of the lack of the hidden
> > > fields. The controller could get very confused and just
> > > foul everything up more and more over time.
> > >
> > > - OVS sends the full match, including NXM fields. Consider
> > > the same situation. The controller may complain bitterly
> > > but it can easily recognize what the situation is, which
> > > gives it some clear options. It could, for example, copy
> > > the raw match bytewise into a flow_mod to delete those flows
> > > individually, or it could just send a "delete all flows"
> > > message.
> > >
> > > [*] One exception is "packet-in" messages, where I think that the
> > > controller should just ignore the extra metadata fields it doesn't
> > > recognize. There isn't the same problem as above in that
> > > situation. (That's why OVS has the "loose" versions of NXM/OXM
> > > parsing.)
> >
> > The test-case was using packet-in messages. So to clarify, it would
> > be best if Ryu ignored unknown OXM fields in packet-in messages?
>
> Yes, I think so.
>
> (What unexpected metadata fields was Ryu getting?)
I'm not entirely sure that this answers you question:
I was seeing an unmasked metadata field with a value of 0;
and register fields whose values and masking I didn't check at the time.
More information about the dev
mailing list