[ovs-discuss] nx_reg_move and ofpat_set_field on arp op

Saul St. John sstjohn at cs.wisc.edu
Fri Mar 8 15:55:41 UTC 2013


On 03/07/2013 10:44 PM, Ben Pfaff wrote:
> On Thu, Mar 07, 2013 at 09:00:49PM -0600, Saul St. John wrote:
>> 1) Is there a reason for not allowing this field as the target of
>> mangling actions?
> I don't know a good one.  I guess that no one has implemented it, and
> that is probably because there has been little demand for it.  (I don't
> remember previous requests.)

Am I correct in thinking that the only change needed to support this 
would be to change the 'writable' boolean in the mf_field for 
NXM_OF_ARP_OP from false to true in lib/meta-flow.c?

>> 3) I don't have a OF1.2-speaking controller at-hand to test this, but it
>> looks like the OFPAT_SET_FIELD action calls the same implementation as
>> the NXM actions. Does OVS enforce the same restrictions on this action?
> Yes.
>
>> If so, is that correct behavior? (I can't tell from the spec if a switch
>> implementation supporting set_field needs to support setting all fields
>> it supports matching (except those excluded in A.2.5).)
> I doubt that a switch implementation is required to support set_field
> for all the fields it supports.  It does not make much sense to change
> some fields; for example, changing the Ethertype is ordinarily going to,
> at most, cause confusion.
I'm not sure I take your point. Any switch that implements the MPLS or 
VLAN push/pop actions is going to need to support ethertype rewriting-- 
so preventing set_field on ethertype would seem to be an artificial 
restriction unmotivated by underlying capabilities. I understand that 
there's usually little utility in directly manipulating that field, and 
that doing so could cause confusion, but I'd suggest that the simplest 
way to prevent that confusion would just be to not set ethertype by 
flow-rule action in the first place.

 From a practical perspective, I'm left wondering if there's any 
practical method for a controller to interrogate a switch's 
field-setting capabilities. (I apologize if that's an o/t subject for 
this list.)



More information about the discuss mailing list