[ovs-discuss] Flow removed message bug

Derek Cormier derek.cormier at lab.ntt.co.jp
Tue Feb 22 01:54:03 UTC 2011


Hi KK,

Thanks for posting this to the openflow-spec board. I do think the 
priority should be maintained since two identical flow matches can exist 
with different priorities. If one of them is removed, it could be useful 
to know which one. To identify a flow uniquely, I believe you need the 
ofp_match & priority (unless a cookie is used).

- Derek

On 02/22/2011 03:27 AM, kk yap wrote:
> Hi,
>
> I believe maintaining the wildcards would be enough.  To me, the
> following two matches are the same:
>
> Wildcards = ALL - DL_TYPE, DL_TYPE = 5, IP_SRC = 100...
> Wildcards = ALL - DL_TYPE, DL_TYPE = 5, IP_SRC = 0...
>
> I believe Ben and Justin is saying that it is reasonable to maintain
> the wildcard field.  Seems like we have a working solution?
>
> I will post this on the openflow-spec list for the words to be cleared
> up.  The priority field worries me a little more, such I think exact
> match is normalized to priority 65535?  Should that be maintained in
> flow_removed?  I wonder.
>
> Regards
> KK
>
> On 21 February 2011 09:30, Ben Pfaff<blp at nicira.com>  wrote:
>> On Sun, Feb 20, 2011 at 11:36 PM, Derek Cormier
>> <derek.cormier at lab.ntt.co.jp>  wrote:
>>> I see what you mean and I agree that a switch shouldn't store unnecessary
>>> information. But is it really a burden in this case? The wildcards are
>>> stored in a single 32-bit integer, so no extra space is needed.
>> The data structure that OVS uses for classification requires that
>> wildcarded fields
>> be zeroed for efficiency reasons.  In other words, storing the wildcards isn't a
>> big deal, but storing nonzero values of wildcarded fields would require extra
>> memory.  So I'd rather not do it, although certainly it's not a huge
>> deal if in the
>> OVS has to.
>>
>> _______________________________________________
>> discuss mailing list
>> discuss at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
>>
>





More information about the discuss mailing list