Message-ID: <1d2b1281-3ac5-4bf0-88d9-6b88e5d42d66@huawei.com>
Date: Fri, 7 Nov 2025 14:26:18 +0300
From: Dmitry Skorodumov <skorodumov.dmitry@...wei.com>
To: Eric Dumazet <edumazet@...gle.com>
CC: <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<andrey.bokhanko@...wei.com>, Andrew Lunn <andrew+netdev@...n.ch>, "David S.
 Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>
Subject: Re: [PATCH net-next 06/14] ipvlan: Support GSO for port -> ipvlan

>> I see that currently there is no any tests for this ipvlan module (may be I missed something).. Do you have any ideas about tests? I'm a bit  confused at the moment: designing tests from scratch - this might be a bit tricky.
>>
>> Or it is enough just describe test-cases I checked manually (in some of the patches of the series)?
> I have some hard time to figure out why you are changing ipvlan, with
> some features that seem quite unrelated.
Sorry! I had to sent a more descriptive cover letter with CC to all maintainers
> ipvlan is heavily used by Google, I am quite reluctant to see a huge
> chunk of changes that I do not understand, without spending hours on
> it.
>
> The MAC-NAT keyword seems more related to a bridge.
>
I tried to make all the new functionality to not affect any existing code. The only place that changes behavior - is "[patch 2] Send mcasts out directly in ipvlan_xmit_mode_l2". May be I should spend some time and invent a way to not change behavior at all. All other places should be under "if (ipvlan_is_macnat(port))".

Now I'd also want to implement some tests, and try to ensure, that existing functionality continues work well. I hope that after review and tests, there will be no bugs.

> The MAC-NAT keyword seems more related to a bridge.

At start of work on this feature, I saw options: 1) Modify IPVLan 2) Modify net/bridge 3) clone IPVLan to new module and extend it

But net/bridge is already overbloated, and I believe it is better not touch it. And IPVlan already has all the required infrastructure functions. Actually, all new functionality - is about 600 lines of diff (patches 1 and 4). The IPVLan is essentially "bridge" in its functionality.. extending it to learn IPs and do mac-nat - is easy. All other diffs - are just improvements (like improve handling IP conflicts, refactor validator/address events handling)

And... i saw a lot of people are already using IPVLan to bridge to WiFi - though with a lot of limitations and troubles.

Here is a bit rewritten documentation (AI also suggests server-case scenarios, but I'm skeptical about it):

+4.4 L2_MACNAT mode:
+-------------------
+
+This mode extends the L2 mode and is primarily designed for desktop virtual
+machines that need to bridge to wireless interfaces. In standard L2 mode,
+you must configure IP addresses on slave interfaces to enable frame
+multiplexing between slaves and the master.
+
+In L2_MACNAT mode, IPVLAN automatically learns IPv4/IPv6 and MAC addresses
+from outgoing packets. For transmitted packets, the source MAC address
+is replaced with the MAC address of the main interface. Received packets
+are routed to the interface that previously used the destination address,
+and the destination MAC is replaced with the learned MAC address.
+
+This enables slave interfaces to automatically obtain IP addresses
+via DHCP and IPv6 autoconfiguration.
+
+Additionally, dev_add_pack() is configured on the master interface to capture
+outgoing frames and multiplex them to slave interfaces when necessary.

Dmitry

Powered by blists - more mailing lists