Thread (63 messages) flat view 63 messages, 7 authors, 2017-09-24

Re: [PATCH net-next 03/14] gtp: Call common functions to get tunnel routes and add dst_cache

From: Tom Herbert <hidden>
Date: 2017-09-19 16:05:19

On Mon, Sep 18, 2017 at 9:17 PM, David Miller [off-list ref] wrote:
From: Tom Herbert <redacted>
Date: Mon, 18 Sep 2017 17:38:53 -0700
quoted
Call ip_tunnel_get_route and dst_cache to pdp context which should
improve performance by obviating the need to perform a route lookup
on every packet.

Signed-off-by: Tom Herbert <redacted>
Not caused by your changes, but something to think about:
quoted
-static struct rtable *ip4_route_output_gtp(struct flowi4 *fl4,
-                                        const struct sock *sk,
-                                        __be32 daddr)
-{
-     memset(fl4, 0, sizeof(*fl4));
-     fl4->flowi4_oif         = sk->sk_bound_dev_if;
-     fl4->daddr              = daddr;
-     fl4->saddr              = inet_sk(sk)->inet_saddr;
-     fl4->flowi4_tos         = RT_CONN_FLAGS(sk);
-     fl4->flowi4_proto       = sk->sk_protocol;
-
-     return ip_route_output_key(sock_net(sk), fl4);
-}
This and the new dst caching code ignores any source address selection
done by ip_route_output_key() or the new tunnel route lookup helpers.

Either source address selection should be respected, or if saddr will
never be modified by a route lookup for some specific reason here,
that should be documented.
Yes, I noticed that. In this case the source address is intended to be
taken bound on the socket which would imply we aren't interested in
source address selection.

Tom
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help