Thread (29 messages) flat view 29 messages, 4 authors, 2015-08-26

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help