netdev - Re: [PATCH net-next v2] eth: fbnic: Add support to write TCE TCAM entries

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: <61830f21-f943-4d84-82c1-fce0e2659ac7@lunn.ch>
Date: Fri, 1 Nov 2024 13:33:23 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Mohsin Bashir <mohsin.bashr@...il.com>
Cc: netdev@...r.kernel.org, alexanderduyck@...com, kuba@...nel.org,
	andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
	pabeni@...hat.com, kernel-team@...a.com, sanmanpradhan@...a.com,
	sdf@...ichev.me, vadim.fedorenko@...ux.dev, hmohsin@...a.com
Subject: Re: [PATCH net-next v2] eth: fbnic: Add support to write TCE TCAM
 entries

On Thu, Oct 31, 2024 at 03:13:40PM -0700, Mohsin Bashir wrote:
> On 10/31/24 5:43 AM, Andrew Lunn wrote:
> > On Wed, Oct 30, 2024 at 05:51:53PM -0700, Mohsin Bashir wrote:
> > > Hi Andrew,
> > > 
> > 
> > > Basically, in addition to the RX TCAM (RPC) that you mentioned, we
> > > also have a TCAM on the TX path that enables traffic redirection for
> > > BMC. Unlike other NICs where BMC diversion is typically handled by
> > > firmware, FBNIC firmware does not touch anything host-related. In
> > > this patch, we are writing MACDA entries from the RPC (Rx Parser and
> > > Classifier) to the TX TCAM, allowing us to reroute any host traffic
> > > destined for BMC.
> > 
> > Two TCAMs, that makes a bit more sense.
> > 
> > But why is this hooked into set_rx_mode? It is nothing to do with RX.
> 
> We are trying to maintain a single central function to handle MAC updates.

So you plan to call set_rx_mode() for any change to the TCAM, for any
reason? When IGMP snooping asks you to add an multicast entry due to
snooping?  ethtool --config-ntuple? Some TC actions? i assume you are
going to call it yourself, not rely on the stack call set_rx_mode()
for you?

> 
> > I assume you have some mechanism to get the MAC address of the BMC. I
> > would of thought you need to write one entry into the TCAM during
> > probe, and you are done?
> > 
> > 	Andrew
> 
> Actually, we may need to write entries in other cases as well. The fact that
> the BMC can come and go independently of the host would result in firmware
> notifying the host of the resulting change. Consequently, the host would
> need to make some changes that will be added in the following patch(es).

And the MAC address changes when the firmware goes away and comes back
again? It is not burned into an OTP/EEPROM? What triggers
set_rx_mode() being called in this condition?

	Andrew