public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru>
To: Michael Dege <michael.dege@renesas.com>,
	Nikita Yushchenko <nikita.yoush@cogentembedded.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Christian Mardmoeller <christian.mardmoeller@renesas.com>,
	Dennis Ostermann <dennis.ostermann@renesas.com>
Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine
Date: Fri, 6 Feb 2026 11:31:47 +0100	[thread overview]
Message-ID: <0299e7dd-e3e1-4514-b335-6b6712d31713@dev.rtsoft.ru> (raw)
In-Reply-To: <TY4PR01MB142820FC29E751D8C7F0B7C348266A@TY4PR01MB14282.jpnprd01.prod.outlook.com>

> Unfortunately, your argumentation is very _academic_. There is _no_practical_reason_, not to
> forward the traffic to the SW bridge via the HW bridge, even if only one link is currently up.

The very practical reason not to forward packet to SW when it can be handled in HW is - reduce SW load. 
SW cores have no chance to handle the load if you forward everything to SW at the channel speed.

The very thing I was trying to achieve when working on this offload support was - detect the case when a 
frame can be processed correctly in HW, and let it process it in HW, without notifying SW. And send 
frame to SW if and only if it is not possible to provide correct processing without that.

But this does not directly affect the case being discussed.

When there is only one port with enabled HW forwarding, there is no effect of keeping HW forwarding 
enabled, because the allowed destination mask computed nearby does not contain any destinations. 
Forwarding to CPU port was never handled via L2 forwarding (*), because L2 forwarding on rswitch 
requires explicit adding any possible destination MAC to the L2 table - which is problematic for CPU 
port, in generic case your software bridge device can be a part of a higher level construct, and you 
will have hard times to dynamically catch and process any changes in the list of possible destination 
MACs for the CPU port. For exact this reason, I implemented forwarding to SW port using "port based" 
thing, that is actually a fallback that rswitch uses when L3/L2 forwarding fails due to no table match.

(*) when virtual ports come into scope, a case for L2 forwarding to CPU port appears.  But still, 
"default" forwarding to SW is never handled as L2 forwarding.

Nikita

  reply	other threads:[~2026-02-06 10:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-05  7:14 [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine Michael Dege
2026-02-05  7:47 ` Nikita Yushchenko
2026-02-05  7:48   ` Nikita Yushchenko
2026-02-05  7:51   ` Michael Dege
2026-02-05  7:58   ` Nikita Yushchenko
2026-02-05 12:49     ` Michael Dege
2026-02-05 13:38       ` Nikita Yushchenko
2026-02-05 13:46         ` Michael Dege
2026-02-05 13:57           ` Nikita Yushchenko
2026-02-05 14:35             ` Michael Dege
2026-02-05 14:41               ` Nikita Yushchenko
2026-02-05 14:44                 ` Nikita Yushchenko
2026-02-06  5:41                   ` Michael Dege
2026-02-06 10:31                     ` Nikita Yushchenko [this message]
2026-02-06 10:34                     ` Nikita Yushchenko
2026-02-06 13:21                       ` Michael Dege
2026-02-06 15:55                       ` Andrew Lunn
2026-02-06 16:10                         ` Nikita Yushchenko
2026-02-06 17:17                           ` Andrew Lunn
2026-02-05 15:03                 ` Nikita Yushchenko
2026-02-06  5:54                   ` Michael Dege

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=0299e7dd-e3e1-4514-b335-6b6712d31713@dev.rtsoft.ru \
    --to=nyushchenko@dev.rtsoft.ru \
    --cc=andrew+netdev@lunn.ch \
    --cc=christian.mardmoeller@renesas.com \
    --cc=davem@davemloft.net \
    --cc=dennis.ostermann@renesas.com \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=michael.dege@renesas.com \
    --cc=netdev@vger.kernel.org \
    --cc=nikita.yoush@cogentembedded.com \
    --cc=pabeni@redhat.com \
    --cc=yoshihiro.shimoda.uh@renesas.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