From: Eric Dumazet <redacted>
Date: Wed, 01 Jan 2014 21:56:46 -0800

On Tue, 2013-12-31 at 13:56 -0500, David Miller wrote:

quoted

From: Eric Dumazet <redacted>
Date: Tue, 24 Dec 2013 10:39:06 -0800

quoted

On Mon, 2013-12-23 at 11:28 -0800, Stephen Hemminger wrote:

quoted

The idea is good, but without the destructor there is nothing to keep
the UDP socket from being destroyed while packet is being sent on another
CPU.

I see no requirement of holding a reference on the vxlan UDP socket in
transmit path.

I'm trying to figure out how leaving a dangling socket attached to
skb->sk, as in this original patch, can be OK.

Sorry, I lost track here (vacation time...), what patch are you
referring to ?

http://patchwork.ozlabs.org/patch/304767/

Once we pass the tunnel, we can either :

1) Leave skb->sk set to the original socket sk1 (Say TCP or UDP
producer)

2) Assign skb->sk to the 'socket' used in vxlan (after orphaning and
releasing reference on socket sk1)

 ...

If we chose 1), it makes more sense, because each producer will be
effectively limited by the proper sk->sk_sndbuf limit.

And a socket cannot be destroyed anyway as long as at least one skb is
in flight (with skb->sk set to this socket)

Really, I do not think vxlan should behave in a different way than other
tunnels (GRE, IPIP, SIT, ...), which chose 1) 

Ok, agreed.