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 <yamah...@valinux.co.jp? > > > > > > Signed-off-by: Simon Horman <ho...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
