All of lore.kernel.org
 help / color / mirror / Atom feed
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 :)

...

  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 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.