From: Alexis Bauvin <abauvin@scaleway.com>
To: David Ahern <dsa@cumulusnetworks.com>,
roopa@cumulusnetworks.com, nicolas.dichtel@6wind.com
Cc: netdev@vger.kernel.org, akherbouche@scaleway.com
Subject: Re: [RFC v1 2/3] vxlan: add support for underlay in non-default VRF
Date: Thu, 15 Nov 2018 11:05:30 +0100 [thread overview]
Message-ID: <41C7AE9A-5C5B-4DA0-9C58-16716F710A62@scaleway.com> (raw)
In-Reply-To: <3777c36e-ccc7-2c4d-889b-46730fafc43d@cumulusnetworks.com>
Le 14 nov. 2018 à 20:58, David Ahern <dsa@cumulusnetworks.com> a écrit :
>
> you are making this more specific than it needs to be ....
>
> On 11/14/18 1:31 AM, Alexis Bauvin wrote:
>> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
>> index 27bd586b94b0..7477b5510a04 100644
>> --- a/drivers/net/vxlan.c
>> +++ b/drivers/net/vxlan.c
>> @@ -208,11 +208,23 @@ static inline struct vxlan_rdst *first_remote_rtnl(struct vxlan_fdb *fdb)
>> return list_first_entry(&fdb->remotes, struct vxlan_rdst, list);
>> }
>>
>> +static int vxlan_get_l3mdev(struct net *net, int ifindex)
>> +{
>> + struct net_device *dev;
>> +
>> + dev = __dev_get_by_index(net, ifindex);
>> + while (dev && !netif_is_l3_master(dev))
>> + dev = netdev_master_upper_dev_get(dev);
>> +
>> + return dev ? dev->ifindex : 0;
>> +}
>
> l3mdev_master_ifindex_by_index should work instead of defining this for
> vxlan.
>
> But I do not believe you need this function.
l3mdev_master_ifindex_by_index does not recursively climbs up the master chain.
This means that if the l3mdev is not a direct master of the device, it will not
be found.
E.G. Calling l3mdev_master_ifindex_by_index with the index of eth0 will
return 0:
+------+ +-----+ +----------+
| | | | | |
| eth0 +-----+ br0 +-----+ vrf-blue |
| | | | | |
+------+ +-----+ +----------+
This is because the underlying l3mdev_master_dev_rcu function fetches the master
(br0 in this case), checks whether it is an l3mdev (which it is not), and
returns its index if so.
So if using l3mdev_master_dev_rcu, using eth0 as a lower device will still bind
to no specific device, thus in the default VRF.
Maybe I should have patched l3mdev_master_dev_rcu to do a recursive resolution
(as vxlan_get_l3mdev does), but I don’t know the impact of such a change.
>> +
>> /* Find VXLAN socket based on network namespace, address family and UDP port
>> * and enabled unshareable flags.
>> */
>> static struct vxlan_sock *vxlan_find_sock(struct net *net, sa_family_t family,
>> - __be16 port, u32 flags)
>> + __be16 port, u32 flags,
>> + int l3mdev_ifindex)
>> {
>> struct vxlan_sock *vs;
>>
>> @@ -221,7 +233,8 @@ static struct vxlan_sock *vxlan_find_sock(struct net *net, sa_family_t family,
>> hlist_for_each_entry_rcu(vs, vs_head(net, port), hlist) {
>> if (inet_sk(vs->sock->sk)->inet_sport == port &&
>> vxlan_get_sk_family(vs) == family &&
>> - vs->flags == flags)
>> + vs->flags == flags &&
>> + vs->sock->sk->sk_bound_dev_if == l3mdev_ifindex)
>
> Why not allow the vxlan socket to bind to any ifindex? In that case this
> socket lookup follows what we do for tcp, udp and raw sockets, and you
> don't need to call out vrf / l3mdev directly (ie.,
> s/l3mdev_ifindex/ifindex/g) - it comes for free.
Reword will be done in next version!
next prev parent reply other threads:[~2018-11-15 20:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20181114093104.93286-1-abauvin@scaleway.com>
[not found] ` <20181114093104.93286-2-abauvin@scaleway.com>
2018-11-14 16:07 ` [RFC v1 1/3] udp_tunnel: add config option to bind to a device Nicolas Dichtel
2018-11-14 17:22 ` Alexis Bauvin
[not found] ` <20181114093104.93286-3-abauvin@scaleway.com>
2018-11-14 19:58 ` [RFC v1 2/3] vxlan: add support for underlay in non-default VRF David Ahern
2018-11-15 10:05 ` Alexis Bauvin [this message]
2018-11-16 7:37 ` David Ahern
2018-11-16 10:41 ` Alexis Bauvin
2018-11-16 16:31 ` David Ahern
[not found] ` <20181114093104.93286-4-abauvin@scaleway.com>
2018-11-14 20:04 ` [RFC v1 3/3] vxlan: handle underlay VRF changes David Ahern
2018-11-15 10:06 ` Alexis Bauvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41C7AE9A-5C5B-4DA0-9C58-16716F710A62@scaleway.com \
--to=abauvin@scaleway.com \
--cc=akherbouche@scaleway.com \
--cc=dsa@cumulusnetworks.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=roopa@cumulusnetworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox