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

Chandran, Sugesh sugesh.chandran at intel.com
Tue May 17 08:00:05 UTC 2016



Regards
_Sugesh

> -----Original Message-----
> From: pravin shelar [mailto:pshelar at ovn.org]
> Sent: Monday, May 16, 2016 7:16 PM
> To: Chandran, Sugesh <sugesh.chandran at intel.com>
> Cc: Daniele Di Proietto <diproiettod at ovn.org>; ovs dev
> <dev at 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.chandran at intel.com> wrote:
> >
> >
> > 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.
> 
> 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 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