From: Petr Machata <petrm@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Petr Machata <petrm@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
"David Ahern" <dsahern@gmail.com>, <netdev@vger.kernel.org>,
Simon Horman <horms@kernel.org>,
Nikolay Aleksandrov <razor@blackwall.org>,
Ido Schimmel <idosch@nvidia.com>, <mlxsw@nvidia.com>
Subject: Re: [PATCH net-next 00/14] ipmr, ip6mr: Allow MC-routing locally-generated MC packets
Date: Tue, 10 Jun 2025 15:12:55 +0200 [thread overview]
Message-ID: <87wm9jeo3n.fsf@nvidia.com> (raw)
In-Reply-To: <20250610055856.5ca1558a@kernel.org>
Jakub Kicinski <kuba@kernel.org> writes:
> On Mon, 9 Jun 2025 22:50:16 +0200 Petr Machata wrote:
>> Multicast routing is today handled in the input path. Locally generated MC
>> packets don't hit the IPMR code. Thus if a VXLAN remote address is
>> multicast, the driver needs to set an OIF during route lookup. In practice
>> that means that 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.
>
> I think this leads to kmemleaks:
> [...]
> hit by netdevsim udp_tunnel_nic.sh
Thanks, I'll take a look.
> Also, do you have a branch with the iproute2 patches we could pull
> in the CI?
My bad, didn't think of it:
https://github.com/pmachata/iproute2/commits/vxlan_mc_ul/
next prev parent reply other threads:[~2025-06-10 13:14 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 20:50 [PATCH net-next 00/14] ipmr, ip6mr: Allow MC-routing locally-generated MC packets Petr Machata
2025-06-09 20:50 ` [PATCH net-next 01/14] net: ipv4: Add a flags argument to iptunnel_xmit(), udp_tunnel_xmit_skb() Petr Machata
2025-06-12 10:28 ` Nikolay Aleksandrov
2025-06-12 11:21 ` Antonio Quartulli
2025-06-09 20:50 ` [PATCH net-next 02/14] net: ipv4: ipmr: ipmr_queue_xmit(): Drop local variable `dev' Petr Machata
2025-06-12 10:28 ` Nikolay Aleksandrov
2025-06-09 20:50 ` [PATCH net-next 03/14] net: ipv4: ipmr: Split ipmr_queue_xmit() in two Petr Machata
2025-06-12 10:29 ` Nikolay Aleksandrov
2025-06-09 20:50 ` [PATCH net-next 04/14] net: ipv4: Add ip_mr_output() Petr Machata
2025-06-09 20:50 ` [PATCH net-next 05/14] net: ipv6: Make udp_tunnel6_xmit_skb() void Petr Machata
2025-06-12 10:29 ` Nikolay Aleksandrov
2025-06-09 20:50 ` [PATCH net-next 06/14] net: ipv6: Add a flags argument to ip6tunnel_xmit(), udp_tunnel6_xmit_skb() Petr Machata
2025-06-12 10:30 ` Nikolay Aleksandrov
2025-06-09 20:50 ` [PATCH net-next 07/14] net: ipv6: ip6mr: Fix in/out netdev to pass to the FORWARD chain Petr Machata
2025-06-12 10:30 ` Nikolay Aleksandrov
2025-06-09 20:50 ` [PATCH net-next 08/14] net: ipv6: ip6mr: Extract a helper out of ip6mr_forward2() Petr Machata
2025-06-12 10:31 ` Nikolay Aleksandrov
2025-06-09 20:50 ` [PATCH net-next 09/14] net: ipv6: Add ip6_mr_output() Petr Machata
2025-06-12 10:35 ` Nikolay Aleksandrov
2025-06-09 20:50 ` [PATCH net-next 10/14] vxlan: Support MC routing in the underlay Petr Machata
2025-06-12 10:36 ` Nikolay Aleksandrov
2025-06-09 20:50 ` [PATCH net-next 11/14] selftests: forwarding: lib: Move smcrouted helpers here Petr Machata
2025-06-12 10:38 ` Nikolay Aleksandrov
2025-06-09 20:50 ` [PATCH net-next 12/14] selftests: net: lib: Add ip_link_has_flag() Petr Machata
2025-06-12 10:38 ` Nikolay Aleksandrov
2025-06-09 20:50 ` [PATCH net-next 13/14] selftests: forwarding: adf_mcd_start(): Allow configuring custom interfaces Petr Machata
2025-06-12 10:38 ` Nikolay Aleksandrov
2025-06-09 20:50 ` [PATCH net-next 14/14] selftests: forwarding: Add a test for verifying VXLAN MC underlay Petr Machata
2025-06-10 13:02 ` Jakub Kicinski
2025-06-10 16:22 ` Petr Machata
2025-06-10 12:58 ` [PATCH net-next 00/14] ipmr, ip6mr: Allow MC-routing locally-generated MC packets Jakub Kicinski
2025-06-10 13:12 ` Petr Machata [this message]
2025-06-11 15:30 ` Petr Machata
2025-06-11 20:23 ` Jakub Kicinski
2025-06-11 21:03 ` Kuniyuki Iwashima
2025-06-12 12:02 ` Petr Machata
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=87wm9jeo3n.fsf@nvidia.com \
--to=petrm@nvidia.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=mlxsw@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.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.