how to extend bond device features to support tunneling offloads

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