[ovs-dev] [PATCH 2/6] datapath: Support VXLAN Group Policy extension

[Pravin Shelar]

On Thu, Feb 5, 2015 at 6:11 PM, Jesse Gross <jesse at nicira.com> wrote:
> On Thu, Feb 5, 2015 at 6:02 PM, Pravin Shelar <pshelar at nicira.com> wrote:
>> On Thu, Feb 5, 2015 at 1:47 PM, Thomas Graf <tgraf at noironetworks.com> wrote:
>>> On 02/05/15 at 11:58am, Pravin Shelar wrote:
>>>> On Thu, Feb 5, 2015 at 2:37 AM, Thomas Graf <tgraf at noironetworks.com> wrote:
>>>> > I kept it because vxlan_sock only holds the receive side flags only
>>>> > as masked with VXLAN_F_RCV_FLAGS. GBP is not split into a receive and
>>>> > transmit flag so your suggestion would work for GBP but as we introduce
>>>> > support for RCO, we need to keep the VXLAN_F_REMCSUM_TX flag in the
>>>> > vport somewhere.
>>>> >
>>>> for RCO I thought vxlan flags will be read from set tunnel parameters.
>>>> But we can discuss it once we have the patch. For GBP I do not see
>>>> need to keep it in vport.
>>>
>>> We need to store the RCO transmit flag somewhere. We need a counter
>>> part to the flags member of struct vxlan_dev. Not only for RCO but
>>> also to support IPv6 or to make the checksum behaviour configurable.
>>>
>>
>> As far as RCO TX flag is concerned it can be part of set tunnel
>> parameters from the set tunnel action. That is inline with OVS flow
>> based tunneling.
>>
>>> I agree, it's not needed for GBP as-is. I would like to avoid
>>> removing it now just to add it again in two weeks. In particular as
>>> changing this would also diverge with the upstream kernel.
>>>
>>> That said, if you feel strongly about this I will change it.
>>
>> Since it should be possible to configure vxlan tunnel with only
>> REMCSUM_RX or only REMCSUM_TX, I do not think we can store REMCSUM_TX
>> in global vport, anyways I do not want to discuss details here. tunnel
>> parameter are part of tunnel action. Thats why we should not make it
>> part of vxlan-vport.
>
> I think this is somewhat problematic because these options affect the
> interpretation of bits on receive. They're all stomping on top of each
> other and there is no way to know what to do unless you are told (and
> the kernel needs to know in this case to handle the checksum on a
> per-packet basis).
>
OK, that is unfortunate as it does not allow vxlan port sharing and we
need to keep flags in vxlan vport.

> We should also think about how to apply this in a consistent manner to
> other protocols that don't have this issue like Geneve.