All of lore.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.com \
    --cc=edumazet@google.com \
    --cc=j.vosburgh@gmail.com \
    --cc=joseph.gasparakis@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pshelar@nicira.com \
    --cc=vfalico@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.