lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4599e35b-eb2b-4d12-82c7-f2a8a804e08f@quicinc.com>
Date: Tue, 14 Jan 2025 19:29:35 +0800
From: Lei Wei <quic_leiwei@...cinc.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Luo Jie <quic_luoj@...cinc.com>, Andrew Lunn <andrew+netdev@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, "Rob
 Herring" <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        "Conor
 Dooley" <conor+dt@...nel.org>,
        Suruchi Agarwal <quic_suruchia@...cinc.com>,
        Pavithra R <quic_pavir@...cinc.com>, Simon Horman <horms@...nel.org>,
        Jonathan Corbet <corbet@....net>, Kees Cook <kees@...nel.org>,
        "Gustavo A. R.
 Silva" <gustavoars@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        <linux-arm-msm@...r.kernel.org>, <netdev@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-doc@...r.kernel.org>, <linux-hardening@...r.kernel.org>,
        <quic_kkumarcs@...cinc.com>, <quic_linchen@...cinc.com>,
        <srinivas.kandagatla@...aro.org>, <bartosz.golaszewski@...aro.org>,
        <john@...ozen.org>
Subject: Re: [PATCH net-next v2 12/14] net: ethernet: qualcomm: Initialize PPE
 L2 bridge settings



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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ