[ovs-dev] [nxast_controller 2/2] Add ability to direct "packet-in"s to particular controllers.

Ben Pfaff blp at nicira.com
Mon Feb 27 21:20:40 UTC 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.

Thank you.

I pushed this out.



More information about the dev mailing list