From: Sridhar Samudrala <sri@us.ibm.com>
To: David Miller <davem@davemloft.net>
Cc: amwang@redhat.com, netdev@vger.kernel.org
Subject: Re: [Patch net-next] vxlan: revert "vxlan: Bypass encapsulation if the destination is local"
Date: Fri, 12 Apr 2013 16:07:41 -0700 [thread overview]
Message-ID: <516893BD.20303@us.ibm.com> (raw)
In-Reply-To: <20130412.151916.63924835658790088.davem@davemloft.net>
On 4/12/2013 12:19 PM, David Miller wrote:
> From: Sridhar Samudrala <sri@us.ibm.com>
> Date: Thu, 11 Apr 2013 16:59:59 -0700
>
>> @@ -1013,7 +1013,7 @@ static netdev_tx_t vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
>> }
>>
>> /* Bypass encapsulation if the destination is local */
>> - if (rt->rt_flags & RTCF_LOCAL) {
>> + if (rt->dst.dev->flags & IFF_LOOPBACK) {
>> struct vxlan_dev *dst_vxlan;
> This looks terrible, and ad-hoc. You need to find a cleaner
> way to express exactly what you're trying to do otherwise I'm
> reverting your change.
The idea is to bypass encap if the destination vxlan endpoint is on the same
host. To do this, i thought it is good enough to check if the route to reach
the destination ip is a local route.(RTCF_LOCAL is set).
This works fine for all the cases where destination ip is assigned to a
normal ethernet device. rt->dst.dev points to loopback device.
In case of veth(veth0,veth1), where the peer(veth1) and the destination
vxlan
endpoint are on a different netns, ip_route_output for veth1's ipis
returning
a route entry that has RTCF_LOCAL set and rt->dst.dev pointing to veth0.
Is it a bug that RTCF_LOCAL is set here when veth0's peer is moved to a
different netns?
We don't want to bypass encap in this scenario.
To address this behavior seen with veth, i had to change the if
condition to
check for rt->dst.dev->flags rather than rt->rt_flags.
Thanks
Sridhar
next prev parent reply other threads:[~2013-04-12 23:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-09 9:57 [Patch net-next] vxlan: revert "vxlan: Bypass encapsulation if the destination is local" Cong Wang
2013-04-09 17:16 ` David Miller
2013-04-09 18:08 ` Sridhar Samudrala
2013-04-10 14:29 ` Sergei Shtylyov
2013-04-11 2:10 ` Cong Wang
2013-04-11 4:53 ` Sridhar Samudrala
2013-04-11 5:55 ` Cong Wang
2013-04-11 6:33 ` Sridhar Samudrala
2013-04-11 23:59 ` Sridhar Samudrala
2013-04-12 8:05 ` Cong Wang
2013-04-12 19:19 ` David Miller
2013-04-12 23:07 ` Sridhar Samudrala [this message]
2013-04-12 23:17 ` David Miller
2013-04-15 2:31 ` Cong Wang
2013-04-15 4:20 ` Sridhar Samudrala
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=516893BD.20303@us.ibm.com \
--to=sri@us.ibm.com \
--cc=amwang@redhat.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.