On Mon, Feb 27, 2012 at 01:06:19PM -0800, Ethan Jackson wrote: > > Yes, it is odd. I chose to do it that way in case, in the future, we > > decide that we need longer controller IDs. If we do that, then we can > > keep using the same struct here, just changing the ovs_be16 to an > > ovs_be32 or ovs_be64. Admittedly it's strange, but I didn't see a > > reason that it was a bad idea. > > Sounds reasonable. > > >> ofp-errors.h: > >> I like the addition of OFPERR_NXBRC_MUST_BE_ZERO. This isn't the > >> appropriate place to do it, but I think we have a lot of other actions > >> which could benefit from returning this error. Is it worth taking the > >> time to find the places which could use it, i.e. sense it doesn't > >> actually get sent on the wire, are there other benefits? > > > > I'm not sure what you mean by saying that it doesn't actually get sent > > on the wire. If a function returns that error, then the error will > > get sent to the controller. Can you explain further? > > NVM I had thoroughly confused myself. This looks correct to me. > > >> I think it may be cleaner to follow the precedent of > >> NXAST_RESUBMIT_TABLE and NXAST_OUTPUT_REG and create an OFPAT_ACTION > >> for controller, and an NXAST_ACTION for controller which uses NULL as > >> it's string. This may require some minor tweaks in the rest of the > >> patch. > > > > I don't follow here. Can you explain further? > > I realize now that my thinking on this issue was mistaken. I was > noticing that when two actions share the same name (e.g. like > NXAST_RESUBMIT and NXAST_RESUBMIT_TABLE) we define both of them in > ofp-util.def, of course this doesn't apply in this case because the > OF1.1 way is to output to the controller port, and the NXAST way is to > use the controller action. My mistake.
Thank you. I pushed this out. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
