[ovs-dev] [PATCH 02/24] nx-match: Do not include NXM only matches when putting an OMX match
Ben Pfaff
blp at nicira.com
Wed Jul 25 00:20:20 UTC 2012
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.)
More information about the dev
mailing list