[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b730469d-4f2c-4418-b642-8c3523d49cc2@blackwall.org>
Date: Thu, 12 Jun 2025 13:35:39 +0300
From: Nikolay Aleksandrov <razor@...ckwall.org>
To: Petr Machata <petrm@...dia.com>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, David Ahern <dsahern@...il.com>,
netdev@...r.kernel.org
Cc: Simon Horman <horms@...nel.org>, Ido Schimmel <idosch@...dia.com>,
mlxsw@...dia.com
Subject: Re: [PATCH net-next 09/14] net: ipv6: Add ip6_mr_output()
On 6/9/25 23:50, Petr Machata wrote:
> Multicast routing is today handled in the input path. Locally generated MC
> packets don't hit the IPMR code today. Thus if a VXLAN remote address is
> multicast, the driver needs to set an OIF during route lookup. Thus MC
> routing configuration needs to be kept in sync with the VXLAN FDB and MDB.
> Ideally, the VXLAN packets would be routed by the MC routing code instead.
>
> To that end, this patch adds support to route locally generated multicast
> packets. The newly-added routines do largely what ip6_mr_input() and
> ip6_mr_forward() do: make an MR cache lookup to find where to send the
> packets, and use ip6_output() to send each of them. When no cache entry is
> found, the packet is punted to the daemon for resolution.
>
> Similarly to the IPv4 case in a previous patch, the new logic is contingent
> on a newly-added IP6CB flag being set.
>
> Signed-off-by: Petr Machata <petrm@...dia.com>
> Reviewed-by: Ido Schimmel <idosch@...dia.com>
> ---
> include/linux/ipv6.h | 1 +
> include/linux/mroute6.h | 7 +++
> net/ipv6/ip6mr.c | 114 ++++++++++++++++++++++++++++++++++++++++
> net/ipv6/route.c | 1 +
> 4 files changed, 123 insertions(+)
>
Looks good to me,
Reviewed-by: Nikolay Aleksandrov <razor@...ckwall.org>
Powered by blists - more mailing lists