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

pravin shelar pshelar at ovn.org
Thu May 12 20:40:31 UTC 2016


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.


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



More information about the dev mailing list