On 23 September 2016 at 12:13, Justin Pettit <jpet...@ovn.org> wrote:
>
>> On Sep 23, 2016, at 10:10 AM, Joe Stringer <j...@ovn.org> wrote:
>>
>> On 23 September 2016 at 01:53, Justin Pettit <jpet...@ovn.org> wrote:
>>>
>>> diff --git a/include/openflow/nicira-ext.h b/include/openflow/nicira-ext.h
>>> index 5ab026c..9d53623 100644
>>> --- a/include/openflow/nicira-ext.h
>>> +++ b/include/openflow/nicira-ext.h
>>> @@ -1128,5 +1128,14 @@ struct nx_tlv_table_reply {
>>>                                 from the length field in the header. */
>>> };
>>> OFP_ASSERT(sizeof(struct nx_tlv_table_reply) == 16);
>>> +
>>> +/* NXT_CT_FLUSH_ZONE.
>>> + *
>>> + * Flushes the connection tracking table. */
>>> +struct nx_zone_id {
>>> +    uint8_t zero[6];            /* Must be zero. */
>>> +    ovs_be16 zone_id;           /* Connection tracking zone. */
>>> +};
>>> +OFP_ASSERT(sizeof(struct nx_zone_id) == 8);
>>
>> Can we use OXMs for this? I could foresee people wanting to apply
>> additional constraints such as mark, label, and potentially other
>> fields in future. We can reject the others for now, but since this is
>> an OpenFlow (extension) API change it'd be good to provide something
>> extensible.
>
> It's a good suggestion.  That would be more of a selective delete than a 
> flush command, which is more general.  However, since we're up against the 
> 2.6 release and it's easy enough to add another extension, I'd prefer to 
> commit this as-is.  We're going to need to build out the OpenFlow interfaces 
> for handling individual conntrack entries anyway, so let's just add the 
> selective deletes along with the dumping commands at the same time.

A message type with the semantics of "delete with 0 or more
constraints" would allow not just /more/ selective deletion, but also
/less/ selective deletion - eg, flush all zones. We already have the
same functionality of this patch with "ovs-appctl
dpctl/flush-conntrack", so I think it's really unfortunate to be
defining such a specific message type in OpenFlow as well when we know
we'll have to go back and do it properly later.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to