[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20171016.213045.2192579343279686077.davem@davemloft.net>
Date: Mon, 16 Oct 2017 21:30:45 +0100 (WEST)
From: David Miller <davem@...emloft.net>
To: jiri@...nulli.us
Cc: netdev@...r.kernel.org, petrm@...lanox.com, idosch@...lanox.com,
mlxsw@...lanox.com
Subject: Re: [patch net-next 0/5] mlxsw: GRE: Offload decap without encap
From: Jiri Pirko <jiri@...nulli.us>
Date: Mon, 16 Oct 2017 16:26:34 +0200
> From: Jiri Pirko <jiri@...lanox.com>
>
> Petr says:
>
> The current code doesn't offload GRE decapsulation unless there's a
> corresponding encapsulation route as well. While not strictly incorrect (when
> encap route is absent, the decap route traps traffic to CPU and the kernel
> handles it), it's a missed optimization opportunity.
>
> With this patchset, IPIP entries are created as soon as offloadable tunneling
> netdevice is created. This then leads to offloading of decap route, if one
> exists, or is added afterwards, even when no encap route is present.
>
> In Linux, when there is a decap route, matching IP-in-IP packets are always
> decapsulated. However, with IPv4 overlays in particular, whether the inner
> packet is then forwarded depends on setting of net.ipv4.conf.*.rp_filter. When
> RP filtering is turned on, inner packets aren't forwarded unless there's a
> matching encap route. The mlxsw driver doesn't reflect this behavior in other
> router interfaces, and thus it's not implemented for tunnel types either. A
> better support for this will be subject of follow-up work.
Series applied.
Powered by blists - more mailing lists