From: Lei Wei <quic_leiwei@quicinc.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Luo Jie <quic_luoj@quicinc.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>,
"Rob Herring" <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
Suruchi Agarwal <quic_suruchia@quicinc.com>,
Pavithra R <quic_pavir@quicinc.com>,
Simon Horman <horms@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
Kees Cook <kees@kernel.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
<linux-arm-msm@vger.kernel.org>, <netdev@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-doc@vger.kernel.org>, <linux-hardening@vger.kernel.org>,
<quic_kkumarcs@quicinc.com>, <quic_linchen@quicinc.com>,
<srinivas.kandagatla@linaro.org>,
<bartosz.golaszewski@linaro.org>, <john@phrozen.org>
Subject: Re: [PATCH net-next v2 12/14] net: ethernet: qualcomm: Initialize PPE L2 bridge settings
Date: Tue, 14 Jan 2025 19:29:35 +0800 [thread overview]
Message-ID: <4599e35b-eb2b-4d12-82c7-f2a8a804e08f@quicinc.com> (raw)
In-Reply-To: <8bdde187-b329-480d-a745-16871276a331@lunn.ch>
On 1/13/2025 9:37 PM, Andrew Lunn wrote:
>>> Why is learning needed on physical ports? In general, switches forward
>>> unknown destination addresses to the CPU. Which is what you want when
>>> the ports are isolated from each other. Everything goes to the
>>> CPU. But maybe this switch does not work like this?
>>>
>>
>> L2 forwarding can be disabled in PPE in two ways:
>>
>> 1.) Keep the learning enabled (which is the default HW setting) and
>> configure the FDB-miss-action to redirect to CPU.
>>
>> This works because even if FDB learning is enabled, we need to represent
>> the bridge and the physical ports using their 'virtual switch instance'
>> (VSI) in the PPE HW, and create the 'port membership' for the bridge VSI
>> (the list of slave ports), before FDB based forwarding can take place. Since
>> we do not yet support switchdev, these VSI are not created and packets are
>> always forwarded to CPU due to FDB miss.
>>
>> (or)
>>
>> 2.) Explicitly disable learning either globally or on the ports.
>>
>> With method 1 we can achieve packet forwarding to CPU without explicitly
>> disabling learning. When switchdev is enabled later, L2 forwarding can be
>> enabled as a natural extension on top of this configuration. So we have
>> chosen the first approach.
>
> How does ageing work in this setup? Will a cable unplug/plug flush all
> the learned entries? Is ageing set to some reasonable default in case
> a MAC address moves?
>
I would like to clarify that representing the bridge and its slave ports
inside PPE (using a VSI - virtual switch instance) is a pre-requisite
before learning can take place on a port. At this point, since switchdev
is not enabled, VSI is not created for port/bridge and hence FDB
learning does not take place. Later when we enable switchdev and
represent the bridge/slave-ports in PPE, FDB learning will automatically
occur on top of this initial configuration. I will add this note in the
comments and commit message to make it clear.
Regarding FDB entry ageing (when switchdev is enabled later), MAC
address move can be automatically detected and old entry flushed by the
PPE. However for link change events on a port, PPE will rely on software
to flush FDB entries for the port.
> Andrew
next prev parent reply other threads:[~2025-01-14 11:30 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 13:47 [PATCH net-next v2 00/14] Add PPE driver for Qualcomm IPQ9574 SoC Luo Jie
2025-01-08 13:47 ` [PATCH net-next v2 01/14] dt-bindings: net: Add PPE " Luo Jie
2025-01-09 9:15 ` Krzysztof Kozlowski
2025-01-10 15:47 ` Jie Luo
2025-01-08 13:47 ` [PATCH net-next v2 02/14] docs: networking: Add PPE driver documentation " Luo Jie
2025-01-08 13:47 ` [PATCH net-next v2 03/14] net: ethernet: qualcomm: Add PPE driver for " Luo Jie
2025-01-08 19:19 ` Christophe JAILLET
2025-01-09 14:18 ` Jie Luo
2025-01-08 13:47 ` [PATCH net-next v2 04/14] net: ethernet: qualcomm: Initialize PPE buffer management for IPQ9574 Luo Jie
2025-01-09 17:27 ` Simon Horman
2025-01-09 20:11 ` Simon Horman
2025-01-10 15:42 ` Jie Luo
2025-01-08 13:47 ` [PATCH net-next v2 05/14] net: ethernet: qualcomm: Initialize PPE queue " Luo Jie
2025-01-08 13:47 ` [PATCH net-next v2 06/14] net: ethernet: qualcomm: Initialize the PPE scheduler settings Luo Jie
2025-01-08 19:27 ` Christophe JAILLET
2025-01-09 14:19 ` Jie Luo
2025-01-09 17:42 ` Simon Horman
2025-01-10 15:40 ` Jie Luo
2025-01-08 13:47 ` [PATCH net-next v2 07/14] net: ethernet: qualcomm: Initialize PPE queue settings Luo Jie
2025-01-08 19:29 ` Christophe JAILLET
2025-01-09 14:20 ` Jie Luo
2025-01-09 17:52 ` Simon Horman
2025-01-10 15:38 ` Jie Luo
2025-01-08 13:47 ` [PATCH net-next v2 08/14] net: ethernet: qualcomm: Initialize PPE service code settings Luo Jie
2025-01-09 17:58 ` Simon Horman
2025-01-10 15:36 ` Jie Luo
2025-01-08 13:47 ` [PATCH net-next v2 09/14] net: ethernet: qualcomm: Initialize PPE port control settings Luo Jie
2025-01-08 13:47 ` [PATCH net-next v2 10/14] net: ethernet: qualcomm: Initialize PPE RSS hash settings Luo Jie
2025-01-08 13:47 ` [PATCH net-next v2 11/14] net: ethernet: qualcomm: Initialize PPE queue to Ethernet DMA ring mapping Luo Jie
2025-01-08 13:47 ` [PATCH net-next v2 12/14] net: ethernet: qualcomm: Initialize PPE L2 bridge settings Luo Jie
2025-01-08 16:59 ` Andrew Lunn
2025-01-13 3:39 ` Lei Wei
2025-01-13 13:37 ` Andrew Lunn
2025-01-14 11:29 ` Lei Wei [this message]
2025-01-14 13:02 ` Andrew Lunn
2025-01-15 6:57 ` Lei Wei
2025-01-08 13:47 ` [PATCH net-next v2 13/14] net: ethernet: qualcomm: Add PPE debugfs support for PPE counters Luo Jie
2025-01-08 16:43 ` Andrew Lunn
2025-01-09 14:24 ` Jie Luo
2025-01-08 13:47 ` [PATCH net-next v2 14/14] MAINTAINERS: Add maintainer for Qualcomm PPE driver Luo Jie
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=4599e35b-eb2b-4d12-82c7-f2a8a804e08f@quicinc.com \
--to=quic_leiwei@quicinc.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=bartosz.golaszewski@linaro.org \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=gustavoars@kernel.org \
--cc=horms@kernel.org \
--cc=john@phrozen.org \
--cc=kees@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=quic_kkumarcs@quicinc.com \
--cc=quic_linchen@quicinc.com \
--cc=quic_luoj@quicinc.com \
--cc=quic_pavir@quicinc.com \
--cc=quic_suruchia@quicinc.com \
--cc=robh@kernel.org \
--cc=srinivas.kandagatla@linaro.org \
/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