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. >> 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
