Re: [PATCH net-next v2 7/9] geneve: Consolidate Geneve functionality in single module.

On Wed, Aug 19, 2015 at 12:50 PM, Jesse Gross [off-list ref] wrote:

On Wed, Aug 19, 2015 at 11:49 AM, Pravin Shelar [off-list ref] wrote:

quoted

On Wed, Aug 19, 2015 at 11:37 AM, Jesse Gross [off-list ref] wrote:

quoted

On Wed, Aug 19, 2015 at 11:29 AM, Pravin Shelar [off-list ref] wrote:

quoted

On Wed, Aug 19, 2015 at 11:18 AM, Jesse Gross [off-list ref] wrote:

quoted

My guess is that if the issue from the earlier patch about overlapping
collect_md tunnels is fixed then that might allow us to simplify
things a little further, since for those tunnels we can assume there
is a 1:1 mapping between collect_md tunnels and sockets.

I dont see how it would be different. Can you elaborate on this ?

Mostly just conceptually simpler. Right now it looks like we are doing
some kind of refcounting between devices and tunnels in
geneve_open/stop (I know it's not really but it appears like that in
some ways.) We could just directly assign collect_md in geneve_open()
and do nothing at all in geneve_stop().

If you look at next patch, I have changed geneve_open and stop
further. The change is geneve_open adds tunnel to hash table so that
only device which are open are in hash table. Since geneve_open and
stop is common for both type of tunnel I do not think there can be any
changes even after avoiding overlapping tunnel types in given socket.

I guess I'm not sure why with the later changes it would be
incompatible. All I'm talking about is something pretty small:

geneve_open:
        if (geneve->collect_md)
                gs->collect_md = true;
to
                gs->collect_md = geneve->collect_md;

geneve_close:
remove
        if (geneve->collect_md)
                gs->collect_md = false;
since the socket is about to be freed anyways.

It's not very different in practice but it looks less like refcounting
and more like a 1:1 mapping.

ok, I thought you were talking about socket refcounting. I will make
the changes.