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

Jesse Gross jesse at kernel.org
Mon May 16 21:41:59 UTC 2016


On Mon, May 16, 2016 at 11:16 AM, pravin shelar <pshelar at ovn.org> wrote:
> On Fri, May 13, 2016 at 2:59 AM, Chandran, 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.

I agree that it's not a big deal to revalidate checksums that have
been marked as invalid already - if there are a large number of these
then we have a bigger problem. And a 1% performance loss I guess is OK
too as well if we get a gain in the common use case.

However, I'm most worried about the possibility that there are some
cases where a NIC might simply not validate the checksum at all -
which it could really do for any reasons. Looking at a sampling of
drivers, there are definitely cases where this can occur. In those
cases, it would not mark the checksum as bad and we would assume that
everything is OK, which it is not. That's pretty bad, even if it is
rare, so we probably are better off just waiting for the new version
of DPDK to address this.



More information about the dev mailing list