[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160211121112.3e347ea9@griffin>
Date: Thu, 11 Feb 2016 12:11:12 +0100
From: Jiri Benc <jbenc@...hat.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Thomas Graf <tgraf@...g.ch>,
Pravin B Shelar <pshelar@...ira.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Tom Herbert <therbert@...gle.com>
Subject: Re: [PATCH net-next 4/7] net: use dst_cache for vxlan device
On Thu, 11 Feb 2016 11:12:00 +0100, Paolo Abeni wrote:
> @@ -1857,6 +1867,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
> struct rtable *rt = NULL;
> const struct iphdr *old_iph;
> union vxlan_addr *dst;
> + struct dst_entry *ndst;
> union vxlan_addr remote_ip;
> struct vxlan_metadata _md;
> struct vxlan_metadata *md = &_md;
[...]
> @@ -1982,7 +2015,6 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
> src_port, dst_port, xnet, !udp_sum);
> #if IS_ENABLED(CONFIG_IPV6)
> } else {
> - struct dst_entry *ndst;
> struct in6_addr saddr;
> u32 rt6i_flags;
Please keep the ndst variable local to the else branch, there's no need
to move it.
> @@ -1990,14 +2022,26 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
> goto drop;
> sk = vxlan->vn6_sock->sock->sk;
>
> - ndst = vxlan6_get_route(vxlan, skb,
> - rdst ? rdst->remote_ifindex : 0,
> - &dst->sin6.sin6_addr, &saddr);
> - if (IS_ERR(ndst)) {
> - netdev_dbg(dev, "no route to %pI6\n",
> - &dst->sin6.sin6_addr);
> - dev->stats.tx_carrier_errors++;
> - goto tx_error;
> + use_cache = rdst && !skb->mark;
All of this use_cache stuff belongs to vxlan{6}_get_route. It should
either return the cached route, or look it up and cache it. This will
also make the code less error prone - if we base the route lookup on
more parameters in the future, the decision to skip the cache (because
the route depends on data from the inner packet) will be at the same
place as the added parameters, making it obvious that the cache skip
condition needs to be updated, too.
Overall, I'm not sure how much gain this dst caching will be in real
life, though. It surely looks nice in benchmarks. But as soon as you
step out of the most trivial case and start using TOS and skb marks,
the cache will be ineffective. But then, maybe the most trivial cases
are 90% of the deployment. No idea.
Jiri
--
Jiri Benc
Powered by blists - more mailing lists