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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev