[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240108185806.6214cbe8@kernel.org>
Date: Mon, 8 Jan 2024 18:58:06 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Saeed Mahameed <saeed@...nel.org>
Cc: "Nelson, Shannon" <shannon.nelson@....com>, "David S. Miller"
<davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, Eric Dumazet
<edumazet@...gle.com>, Saeed Mahameed <saeedm@...dia.com>,
netdev@...r.kernel.org, Tariq Toukan <tariqt@...dia.com>, Armen Ratner
<armeng@...dia.com>, Daniel Jurgens <danielj@...dia.com>
Subject: Re: [net-next 15/15] net/mlx5: Implement management PF Ethernet
profile
On Mon, 8 Jan 2024 15:22:12 -0800 Saeed Mahameed wrote:
> This is embedded core switchdev setup, there is no PF representor, only
> uplink and VF/SF representors, the term management PF is only FW
> terminology, since uplink traffic is controlled by the admin, and uplink
> interface represents what goes in/out the wire, the current FW architecture
> demands that BMC/NCSI traffic goes through a separate PF that is not the
> uplink since the uplink rules are managed purely by the eswitch admin.
"Normal way" to talk to the BMC is to send the traffic to the uplink
and let the NC-SI filter "steal" the frames. There's not need for host
PF (which I think is what you're referring to when you say there's
no PF representor).
Can you rephrase / draw a diagram? Perhaps I'm missing something.
When the host is managing the eswitch for mlx5 AFAIU NC-SI frame
stealing works fine.. so I'm missing what's different with the EC.
Powered by blists - more mailing lists