[ovs-dev] [PATCH v2] tunneling: Improving tunneling performance using DPDK Rx checksum offloading feature.

Chandran, Sugesh sugesh.chandran at intel.com
Fri May 13 09:59:43 UTC 2016



Regards
_Sugesh

> -----Original Message-----
> From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Daniele Di
> Proietto
> Sent: Friday, May 13, 2016 2:38 AM
> To: pravin shelar <pshelar at ovn.org>
> Cc: ovs dev <dev at 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 <pshelar at ovn.org>:
> 
> > On Thu, May 12, 2016 at 12:59 PM, Jesse Gross <jesse at kernel.org> wrote:
> > > On Thu, May 12, 2016 at 11:18 AM, pravin shelar <pshelar at ovn.org>
> wrote:
> > >> On Tue, May 10, 2016 at 6:31 PM, Jesse Gross <jesse at 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.  
> 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 at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
> >
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev


More information about the dev mailing list