From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
To: Michael Dege <michael.dege@renesas.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>
Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine
Date: Thu, 5 Feb 2026 15:41:17 +0100 [thread overview]
Message-ID: <a4cfeba2-23da-4fdd-870b-6533b5ce267c@cogentembedded.com> (raw)
In-Reply-To: <TY4PR01MB142829EB0EDDE13B588F949298299A@TY4PR01MB14282.jpnprd01.prod.outlook.com>
>> The driver was originally designed to enable hardware forwarding when not less than two ports are in
>> forwarding state. When only one port has hw forwarding, there is no destination to forward.
>>
>> Nikita
>>
>
> The current driver allows Linux to use the bridge port as local port to the bridge. The offloading
> Also supports switching traffic to Linux through the bridge port. Therefore, the offloading shouldn't
> Be dropped if only one external port is up on the bridge.
"Offloading" means - forward a frame from one hw port to other hw port without inserting it into CPU
queue. Offloaded frame is never visible to software bridge.
There is code that allows offload only if the linux bridge device used to connect rswitch ports does not
have anything else. If it has something else, offloading is disabled (because there is no way to know
when a frame can be processed within rswitch hw without sending it to cpu).
Nikita
next prev parent reply other threads:[~2026-02-05 14:41 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 [this message]
2026-02-05 14:44 ` Nikita Yushchenko
2026-02-06 5:41 ` Michael Dege
2026-02-06 10:31 ` Nikita Yushchenko
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=a4cfeba2-23da-4fdd-870b-6533b5ce267c@cogentembedded.com \
--to=nikita.yoush@cogentembedded.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--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=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