[ovs-dev] [nxast_controller 2/2] Add ability to direct "packet-in"s to particular controllers.
blp at nicira.com
Mon Feb 27 13:20:40 PST 2012
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.
I pushed this out.
More information about the dev