> 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