Subject: how to extend bond device features to support tunneling offloads

From: Or Gerlitz <[email-masked]>
Date: Thu, 12 Jun 2014 16:43:35 +0300

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;
  }