From: Simon Horman <horms@kernel.org>
To: Dmitry Skorodumov <skorodumov.dmitry@huawei.com>
Cc: netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, andrey.bokhanko@huawei.com,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Andrew Lunn <andrew+netdev@lunn.ch>
Subject: Re: [PATCH net-next 1/8] ipvlan: Implement learnable L2-bridge
Date: Thu, 23 Oct 2025 12:31:08 +0100 [thread overview]
Message-ID: <aPoR_HWEgmrs97Qd@horms.kernel.org> (raw)
In-Reply-To: <58174e6d-f473-4e95-b78e-7a4a9711174e@huawei.com>
On Thu, Oct 23, 2025 at 01:21:20PM +0300, Dmitry Skorodumov wrote:
> On 22.10.2025 17:23, Simon Horman wrote:
> > On Tue, Oct 21, 2025 at 05:44:03PM +0300, Dmitry Skorodumov wrote:
> >> Now it is possible to create link in L2E mode: learnable
> >> bridge. The IPs will be learned from TX-packets of child interfaces.
> > Is there a standard for this approach - where does the L2E name come from?
>
> Actually, I meant "E" here as "Extended". But more or less standard naming - is "MAC NAT" - "Mac network address translation". I discussed a bit naming with LLM, and it suggested name "macsnat".. looks like it is a better name. Hope it is ok, but I don't mind to rename if anyone has better idea
I was more curious than anything else. But perhaps it would
be worth providing some explanation of the name in the
commit message.
...
> >> +static void ipvlan_addr_learn(struct ipvl_dev *ipvlan, void *lyr3h,
> >> + int addr_type)
> >> +{
> >> + void *addr = NULL;
> >> + bool is_v6;
> >> +
> >> + switch (addr_type) {
> >> +#if IS_ENABLED(CONFIG_IPV6)
> >> + /* No need to handle IPVL_ICMPV6, since it never has valid src-address */
> >> + case IPVL_IPV6: {
> >> + struct ipv6hdr *ip6h;
> >> +
> >> + ip6h = (struct ipv6hdr *)lyr3h;
> >> + if (!is_ipv6_usable(&ip6h->saddr))
> > It is preferred to avoid #if / #ifdef in order to improve compile coverage
> > (and, I would argue, readability).
> ..
> > In this case I think that can be achieved by changing the line above to:
> >
> > if (!IS_ENABLED(CONFIG_IPV6) || !is_ipv6_usable(&ip6h->saddr))
> >
> > I think it would be interesting to see if a similar approach can be used
> > to remove other #if CONFIG_IPV6 conditions in this file, and if successful
> > provide that as a clean-up as the opening patch in this series.
> >
> > However, without that, I can see how one could argue for the approach
> > you have taken here on the basis of consistency.
> >
>
> Hmmmm.... this raises a complicated for me questions of testing this refactoring:
>
> - whether IPv6 specific functions (like csum_ipv6_magic(), register_inet6addr_notifier()) are available if kernel is compiled without CONFIG_IPV6
>
> - ideally the code should be retested with kernel without CONFIG_IPV6
>
> This looks like a separate work that requires more or less additional efforts...
Understood, I agree this can be left as future work.
>
> > static int ipvlan_xmit_mode_l2(struct sk_buff *skb, struct net_device *dev)
> >> {
> >> - const struct ipvl_dev *ipvlan = netdev_priv(dev);
> >> - struct ethhdr *eth = skb_eth_hdr(skb);
> >> - struct ipvl_addr *addr;
> >> void *lyr3h;
> >> + struct ipvl_addr *addr;
> >> int addr_type;
> >> + bool same_mac_addr;
> >> + struct ipvl_dev *ipvlan = netdev_priv(dev);
> >> + struct ethhdr *eth = skb_eth_hdr(skb);
> > I realise that the convention is not followed in the existing code,
> > but please prefer to arrange local variables in reverse xmas tree order -
> > longest line to shortest.
> I fixed all my changes to follow this style, except one - where it seems a bit unnatural to to declare dependent variable before "parent" variable. Hope it is ok.
I would lean towards reverse xmas here too.
But I understand if you feel otherwise.
And given the current state of this file, I think that is ok.
> >> + ether_addr_equal(eth->h_source, dev->dev_addr)) {
> >> + /* ignore tx-packets from host */
> >> + goto out_drop;
> >> + }
> >> +
> >> + same_mac_addr = ether_addr_equal(eth->h_dest, eth->h_source);
> >> +
> >> + lyr3h = ipvlan_get_L3_hdr(ipvlan->port, skb, &addr_type);
> >>
> >> - if (!ipvlan_is_vepa(ipvlan->port) &&
> >> - ether_addr_equal(eth->h_dest, eth->h_source)) {
> >> - lyr3h = ipvlan_get_L3_hdr(ipvlan->port, skb, &addr_type);
> >> + if (ipvlan_is_learnable(ipvlan->port)) {
> >> + if (lyr3h)
> >> + ipvlan_addr_learn(ipvlan, lyr3h, addr_type);
> >> + /* Mark SKB in advance */
> >> + skb = skb_share_check(skb, GFP_ATOMIC);
> >> + if (!skb)
> >> + return NET_XMIT_DROP;
> > I think that when you drop packets a counter should be incremented.
> > Likewise elsewhere in this function.
> The counter appears to be handled in parent function - in ipvlan_start_xmit()
Thanks, I see that now.
> >> + addr = ipvlan_addr_lookup(port, lyr3h, addr_type, true);
> >> + if (addr) {
> >> + int ret, len;
> >> +
> >> + ipvlan_skb_crossing_ns(skb, addr->master->dev);
> >> + skb->protocol = eth_type_trans(skb, skb->dev);
> >> + skb->pkt_type = PACKET_HOST;
> >> + ipvlan_mark_skb(skb, port->dev);
> >> + len = skb->len + ETH_HLEN;
> >> + ret = netif_rx(skb);
> >> + ipvlan_count_rx(ipvlan, len, ret == NET_RX_SUCCESS, false);
> >>
> >> This fails to build because ipvlan is not declared in this scope.
> >> Perhaps something got missed due to an edit?
> Oops, really. Compilation was fixed in later patches.
Stuff happens :)
...
next prev parent reply other threads:[~2025-10-23 11:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-21 14:44 [PATCH net-next 0/8] ipvlan: Implement learnable L2-bridge Dmitry Skorodumov
2025-10-21 14:44 ` [PATCH net-next 1/8] " Dmitry Skorodumov
2025-10-22 14:23 ` Simon Horman
2025-10-23 10:21 ` Dmitry Skorodumov
2025-10-23 11:31 ` Simon Horman [this message]
2025-10-21 14:44 ` [PATCH net-next 2/8] ipvlan: Send mcasts out directly in ipvlan_xmit_mode_l2() Dmitry Skorodumov
2025-10-21 14:44 ` [PATCH net-next 3/8] ipvlan: Handle rx mcast-ip and unicast eth Dmitry Skorodumov
2025-10-21 14:44 ` [PATCH net-next 4/8] ipvlan: Added some kind of MAC SNAT Dmitry Skorodumov
2025-10-21 14:44 ` [PATCH net-next 5/8] ipvlan: Forget all IP when device goes down Dmitry Skorodumov
2025-10-21 14:44 ` [PATCH net-next 6/8] ipvlan: Support GSO for port -> ipvlan Dmitry Skorodumov
2025-10-22 20:55 ` kernel test robot
2025-10-21 14:44 ` [PATCH net-next 7/8] ipvlan: Support IPv6 for learnable l2-bridge Dmitry Skorodumov
2025-10-23 0:03 ` kernel test robot
2025-10-23 0:24 ` kernel test robot
2025-10-24 2:21 ` kernel test robot
2025-10-21 14:44 ` [PATCH net-next 8/8] ipvlan: Don't learn child with host-ip Dmitry Skorodumov
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=aPoR_HWEgmrs97Qd@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=andrey.bokhanko@huawei.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=skorodumov.dmitry@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).