On Thu, Feb 5, 2015 at 6:02 PM, Pravin Shelar <pshe...@nicira.com> wrote: > On Thu, Feb 5, 2015 at 1:47 PM, Thomas Graf <tg...@noironetworks.com> wrote: >> On 02/05/15 at 11:58am, Pravin Shelar wrote: >>> On Thu, Feb 5, 2015 at 2:37 AM, Thomas Graf <tg...@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). We should also think about how to apply this in a consistent manner to other protocols that don't have this issue like Geneve. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
