From: Jiri Benc <jbenc@redhat.com>
To: Matthias Schiffer <mschiffer@universe-factory.net>
Cc: davem@davemloft.net, hannes@stressinduktion.org, pshelar@ovn.org,
aduyck@mirantis.com, roopa@cumulusnetworks.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 3/3] vxlan: allow multiple VXLANs with same VNI for IPv6 link-local addresses
Date: Tue, 14 Mar 2017 16:28:15 +0100 [thread overview]
Message-ID: <20170314162815.7aae9e94@griffin> (raw)
In-Reply-To: <5c74248483272110d0ca249b80b943b0ceb0b610.1489184335.git.mschiffer@universe-factory.net>
On Fri, 10 Mar 2017 23:39:44 +0100, Matthias Schiffer wrote:
> @@ -233,17 +234,30 @@ static struct vxlan_dev *vxlan_vs_find_vni(struct vxlan_sock *vs, __be32 vni)
> vni = 0;
>
> hlist_for_each_entry_rcu(vxlan, vni_head(vs, vni), hlist) {
> - if (vxlan->default_dst.remote_vni == vni)
> - return vxlan;
> + if (vxlan->default_dst.remote_vni != vni)
> + continue;
> +
> + if (IS_ENABLED(CONFIG_IPV6)) {
> + const struct vxlan_config *cfg = &vxlan->cfg;
> +
> + if (cfg->remote_ifindex != 0 &&
> + cfg->remote_ifindex != ifindex &&
> + cfg->saddr.sa.sa_family == AF_INET6 &&
> + (ipv6_addr_type(&cfg->saddr.sin6.sin6_addr) &
> + IPV6_ADDR_LINKLOCAL))
Calculating this (especially ipv6_addr_type) on every received packet
looks unnecessarily expensive. Just store the fact the the local
address is link-local in a flag during config. And compare the flag
first before considering remote_ifindex.
This is especially important for lwtunnels which can have anything in
the saddr and remote_ifindex, yet those fields are ignored and the
vni 0 entry has to be returned. It also means that the link-local flag
must not be set for lwtunnels.
> +#if IS_ENABLED(CONFIG_IPV6)
> + if (conf->remote_ifindex != tmp->cfg.remote_ifindex &&
> + conf->saddr.sa.sa_family == AF_INET6 &&
> + tmp->cfg.saddr.sa.sa_family == AF_INET6 &&
> + (ipv6_addr_type(&conf->saddr.sin6.sin6_addr) &
> + IPV6_ADDR_LINKLOCAL) &&
> + (ipv6_addr_type(&tmp->cfg.saddr.sin6.sin6_addr) &
> + IPV6_ADDR_LINKLOCAL))
> + continue;
> +#endif
In patch 1, you're checking for either source and destination address
being link-local, while here you're consider only those that have both
addresses link-local.
Wouldn't it be better to plainly reject configuration that has one
address link-local but not the other one?
Jiri
next prev parent reply other threads:[~2017-03-14 15:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-10 22:39 [PATCH net-next 0/3] VXLAN over IPv6 link-local Matthias Schiffer
2017-03-10 22:39 ` [PATCH net-next 1/3] vxlan: don't allow link-local IPv6 local/remote addresses without interface Matthias Schiffer
2017-03-14 14:44 ` Jiri Benc
2017-03-10 22:39 ` [PATCH net-next 2/3] vxlan: fix snooping for link-local IPv6 addresses Matthias Schiffer
2017-03-14 14:56 ` Jiri Benc
2017-03-10 22:39 ` [PATCH net-next 3/3] vxlan: allow multiple VXLANs with same VNI for IPv6 link-local addresses Matthias Schiffer
2017-03-14 15:28 ` Jiri Benc [this message]
2017-03-15 14:29 ` Matthias Schiffer
2017-03-15 15:22 ` Jiri Benc
2017-04-05 16:58 ` Matthias Schiffer
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=20170314162815.7aae9e94@griffin \
--to=jbenc@redhat.com \
--cc=aduyck@mirantis.com \
--cc=davem@davemloft.net \
--cc=hannes@stressinduktion.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mschiffer@universe-factory.net \
--cc=netdev@vger.kernel.org \
--cc=pshelar@ovn.org \
--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;
as well as URLs for NNTP newsgroup(s).