Regards _Sugesh
> -----Original Message----- > From: pravin shelar [mailto:pshe...@ovn.org] > Sent: Monday, May 16, 2016 7:16 PM > To: Chandran, Sugesh <sugesh.chand...@intel.com> > Cc: Daniele Di Proietto <diproiet...@ovn.org>; ovs dev > <dev@openvswitch.org> > Subject: Re: [ovs-dev] [PATCH v2] tunneling: Improving tunneling > performance using DPDK Rx checksum offloading feature. > > On Fri, May 13, 2016 at 2:59 AM, Chandran, Sugesh > <sugesh.chand...@intel.com> wrote: > > > > > > Regards > > _Sugesh > > > >> -----Original Message----- > >> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Daniele > >> Di Proietto > >> Sent: Friday, May 13, 2016 2:38 AM > >> To: pravin shelar <pshe...@ovn.org> > >> Cc: ovs dev <dev@openvswitch.org> > >> Subject: Re: [ovs-dev] [PATCH v2] tunneling: Improving tunneling > >> performance using DPDK Rx checksum offloading feature. > >> > >> 2016-05-12 13:40 GMT-07:00 pravin shelar <pshe...@ovn.org>: > >> > >> > On Thu, May 12, 2016 at 12:59 PM, Jesse Gross <je...@kernel.org> > wrote: > >> > > On Thu, May 12, 2016 at 11:18 AM, pravin shelar <pshe...@ovn.org> > >> wrote: > >> > >> On Tue, May 10, 2016 at 6:31 PM, Jesse Gross <je...@kernel.org> > >> wrote: > >> > >>> I'm a little bit torn as to whether we should apply your rx > >> > >>> checksum offload patch in the meantime while we wait for DPDK > >> > >>> to offer the new API. It looks like we'll have a 10% gain with > >> > >>> tunneling in exchange for a 1% loss in other situations, so the > >> > >>> call obviously depends on use case. Pravin, Daniele, others, > >> > >>> any > >> opinions? > >> > >>> > >> > >> There could be a way around the API issue and avoid the 1% loss. > >> > >> netdev API could be changed to set packet->mbuf.ol_flags to > >> > >> (PKT_RX_IP_CKSUM_BAD | PKT_RX_L4_CKSUM_BAD) if the netdev > >> > >> implementation does not support rx checksum offload. Then there > >> > >> is no need to check the rx checksum flags in dpif-netdev. And > >> > >> the checksum can be directly checked in tunneling code where we > >> > >> actually > >> need to. > >> > >> Is there any issue with this approach? > >> > > > >> > > I think that's probably a little bit cleaner overall though I > >> > > don't think that it totally eliminates the overhead. Not all DPDK > >> > > ports will support checksum offload (since the hardware may not > >> > > do it in > >> > > theory) so we'll still need to check the port status on each > >> > > packet to initialize the flags. > >> > > > >> > I was thinking of changing dpdk packet object constructor > >> > (ovs_rte_pktmbuf_init()) to initialize the flag according to the > >> > device offload support. This way there should not be any checks > >> > needed in packet receive path. > >> > > >> > > >> It looks like (at least for ixgbe) the flags are reset by the rx > >> routine, even if offloads are disabled. > >> > >> I don't have a better idea, IMHO losing 1% is not a huge deal > >> > > [Sugesh] And also setting CKSUM_BAD on packets from unsupported ports > > introduce an additional check in tunneling code, to do the checksum > > calculation only when the port doesn’t support it, not when the packet > > is corrupted and NIC reports it as BAD checksum. Otherwise OVS has to > > do the checksum validation on invalid packets too. > > Today tunneling code does checksum on all packets, so I am not sure what do > you mean here. Anyways I think the proposed approach can work if DPDK rx > routine does not reset the checksum flags unnecessarily. [Sugesh] Just wanted to mention that this approach makes the tunneling code to do the checksum validation even if NIC marked it as invalid packet. This is a unnecessary revalidation.Anyway this doesn’t make any difference as DPDK is resetting the flags in drivers. > >> Thanks > >> > >> > >> > > The other thing that is a little concerning is that there might > >> > > be conditions where a driver doesn't actually verify the > >> > > checksum. I guess most of these aren't supported in our tunneling > >> > > implementation (IP options comes to mind) but it's a little risky. > >> > _______________________________________________ > >> > dev mailing list > >> > dev@openvswitch.org > >> > http://openvswitch.org/mailman/listinfo/dev > >> > > >> _______________________________________________ > >> dev mailing list > >> dev@openvswitch.org > >> http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
