Re: [PATCH v3 net-next 5/8] geneve: Add support to collect tunnel metadata.
From: Pravin Shelar <hidden>
Date: 2015-08-25 21:16:48
On Tue, Aug 25, 2015 at 9:50 AM, Jesse Gross [off-list ref] wrote:
On Mon, Aug 24, 2015 at 7:15 PM, Pravin Shelar [off-list ref] wrote:quoted
On Mon, Aug 24, 2015 at 6:42 PM, Jesse Gross [off-list ref] wrote:quoted
On Mon, Aug 24, 2015 at 10:43 AM, Pravin B Shelar [off-list ref] wrote:quoted
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c index 0a6d974..c05bc13 100644 --- a/drivers/net/geneve.c +++ b/drivers/net/geneve.c@@ -141,10 +190,15 @@ drop: /* Setup stats when device is created */ static int geneve_init(struct net_device *dev) { + struct geneve_dev *geneve = netdev_priv(dev); + dev->tstats = netdev_alloc_pcpu_stats(struct pcpu_sw_netstats); if (!dev->tstats) return -ENOMEM; + if (geneve->collect_md) + dev->features |= NETIF_F_NETNS_LOCAL;I was going back and forth on whether this is the right thing to do. Is it any weirder to allow this than to move a normal tunnel device across namespaces?Moving this device means moving all tunnels backed by this device rather than specific tunnel device. Thats why it does not look right to move such device.I agree it seems weird in general. There were two things that made me wonder: * It doesn't appear that VXLAN or GRE do this. * The use case for moving a single tunnel to a different namespace is to have the device and socket live in different places. I guess conceptually this could apply to collect_md devices as well. (Maybe to have harder isolation between inside and outside the tunnel?) I'm not really sure what the best answer is but at least we should be consistent across tunnel types.
ok, I will drop the feature.