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

Ethan Jackson ethan at nicira.com
Mon Feb 27 21:06:19 UTC 2012


> 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.

Patch looks good,
Ethan


> Thanks,
>
> Ben.



More information about the dev mailing list