> Jan, MD2 is flexible enough, so we mustn't worry there will be one MDx, it
> is very weird to use OVS_NSH_PUSH_ATTR_CONTEXT as sub key of
> OVS_KEY_ATTR_NSH.

There is no point in introducing OVS_NSH_KEY_ATTR_MD2 as we will never transfer 
MD2 TLV context headers as explicit fields neither as for matching in 
OVS_KEY_ATTR_NSH or for setting as part of OVS_ACTION_ATTR_SET/SET_MASKED. MD2 
TLVs will be mapped to some new generic TLV match fields.

> For PUSH_NSH, the below format is clear enough, it won't make people
> confused. Yes, maybe we won't use OVS_NSH_KEY_ATTR_MD2 to transfer
> MD2 match fields, but this isn't a good reason why we want to use a worse
> name.
> 
> OVS_ACTION_ATTR_PUSH_NSH
> -- OVS_NSH_KEY_ATTR_BASE
> -- OVS_NSH_KEY_ATTR_MD1
> 
> Or
> 
> OVS_ACTION_ATTR_PUSH_NSH
> -- OVS_NSH_KEY_ATTR_BASE
> -- OVS_NSH_KEY_ATTR_MD2
> 

This would be a possible alternative solution, but it, for no gain, implies 
more complex code both on sender and receiver. It will also require explicit 
changes on the uAPI and datapath code if ever a new MD type is introduced. I 
don't think that is very far-fetched: One could for example consider MD3 to 
combine the simplicity of MD1 fixed contexts (accessible to HW SFFs) with the 
flexibility of MD2 TLVs (mainly for SFs).

If we should anyway stick to your approach, you should definitely rename 
OVS_NSH_KEY_ATTR_MD2 to OVS_NSH_PUSH_ATTR_MD2.

For comparison again: In my simple and generic approach push_nsh will always be 
represented as 
OVS_ACTION_ATTR_PUSH_NSH
-- OVS_NSH_KEY_ATTR_BASE   (mandatory)
-- OVS_NSH_PUSH_ATTR_CONTEXT   (optional)

> I have worked out a version with ttl key and aligned to the lasted NSH draft,
> I have double confirmed from its author, this will be final version, NSH
> header format won't be changed anymore except some text changes, I'll
> send out this version today to catch up with OVS guys' review, kernel
> version will be sent out later today.

That is good news. I am looking forward to seeing the changed version.

BR, Jan

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to