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

pravin shelar pshelar at ovn.org
Mon May 16 18:16:21 UTC 2016


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.

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