On Thu, Feb 5, 2015 at 6:11 PM, Jesse Gross <je...@nicira.com> wrote: > 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). > 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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
