Merge branch 'geneve-udp-port-offload'
authorDavid S. Miller <davem@davemloft.net>
Wed, 16 Dec 2015 15:59:05 +0000 (10:59 -0500)
committerDavid S. Miller <davem@davemloft.net>
Wed, 16 Dec 2015 15:59:05 +0000 (10:59 -0500)
commit897ca373be8461efc880cc3288ffcbc2e1fa03b0
tree25ec23b5c389cda057a187a592012bea268114bb
parent566178f853c1aa57be9c16007c7cca07df5d51b6
parentcd866606c91b1e99517fd866de0049276f011ea7
Merge branch 'geneve-udp-port-offload'

Anjali Singhai Jain says:

====================
Add support for Geneve udp port offload

This patch series adds new ndo ops for Geneve add/del port, so as
to help offload Geneve tunnel functionalities such as RX checksum,
RSS, filters etc.

i40e driver has been tested with the changes to make sure the offloads
happen.

We do understand that this is not the ideal solution and most likely
will be redone with a more generic offload framework.
But this certainly will enable us to start seeing benefits of the
accelerations for Geneve tunnels.

As a side note, we did find an existing issue in i40e driver where a
service task can modify tunnel data structures with no locks held to
help linearize access. A separate patch will be taking care of that issue.

A question out to the community is regarding the driver Kconfig parameters
for VxLAN and Geneve, it would be ideal to drop those if there is a way
to help resolve vxlan/geneve_get_rx_port symbols while the tunnel modules
are not loaded.

Performance numbers:
With the offloads enable on X722 devices with remote checksum enabled
and no other tuning in terms of cpu governer etc on my test machine:

With offload
Throughput: 5527Mbits/sec with a single thread
%cpu: ~43% per core with 4 threads

Without offload
Throughput: 2364Mbits/sec with a single thread
%cpu: ~99% per core with 4 threads

These numbers will get better for X722 as it is being worked. But
this does bring out the delta in terms of when the stack is notified
with csum_level 1 and CHECKSUM_UNNECESSARY vs not without the RX offload.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>