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
next prev parent 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