public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Or Gerlitz <ogerlitz@mellanox•com>
To: Eric Dumazet <edumazet@google•com>,
	Jay Vosburgh <j.vosburgh@gmail•com>,
	Veaceslav Falico <vfalico@gmail•com>
Cc: netdev <netdev@vger•kernel.org>,
	Pravin B Shelar <pshelar@nicira•com>,
	Joseph Gasparakis <joseph.gasparakis@intel•com>
Subject: how to extend bond device features to support  tunneling offloads
Date: Thu, 12 Jun 2014 16:43:35 +0300	[thread overview]
Message-ID: <5399AE87.1040308@mellanox.com> (raw)

So we realized that when bonding is used, the TX path of the IP stack 
above becomes blind to whether the
underlying NIC supports tunneling offloads :(

In a slightly different context, this is addressed for veth in commit 
82d8189 "veth: extend features to support tunneling"  -- now, doing 
quick test with the below RFC patch, I have VXLAN traffic over bonding 
to go through HW LSO where w.o the patch it doesn't.

Do people think bonding needs to recompute the tunneling related 
features (e.g @ hw_features andhw_enc_features) each time the active 
slave changes or we can blindly (...) do it when the bond device is 
being setup in a similar manner to how Eric's patch goes?

Or.


diff --git a/drivers/net/bonding/bond_main.c 
b/drivers/net/bonding/bond_main.c
index d3a6789..3ef6504 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3891,6 +3891,11 @@ static void bond_destructor(struct net_device 
*bond_dev)
         free_netdev(bond_dev);
  }

+
+#define BOND_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_ALL_TSO 
|    \
+                      NETIF_F_HW_CSUM | NETIF_F_RXCSUM | 
NETIF_F_HIGHDMA | \
+                      NETIF_F_GSO_UDP_TUNNEL)
+
  void bond_setup(struct net_device *bond_dev)
  {
         struct bonding *bond = netdev_priv(bond_dev);
@@ -3945,6 +3950,8 @@ void bond_setup(struct net_device *bond_dev)
NETIF_F_HW_VLAN_CTAG_FILTER;

         bond_dev->hw_features &= ~(NETIF_F_ALL_CSUM & ~NETIF_F_HW_CSUM);
+       bond_dev->hw_features |= NETIF_F_GSO_UDP_TUNNEL;
+       bond_dev->hw_enc_features  = BOND_FEATURES;
         bond_dev->features |= bond_dev->hw_features;
  }

                 reply	other threads:[~2014-06-12 13:47 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5399AE87.1040308@mellanox.com \
    --to=ogerlitz@mellanox$(echo .)com \
    --cc=edumazet@google$(echo .)com \
    --cc=j.vosburgh@gmail$(echo .)com \
    --cc=joseph.gasparakis@intel$(echo .)com \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=pshelar@nicira$(echo .)com \
    --cc=vfalico@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox