netdev - Re: [net-next 15/15] net/mlx5: Implement management PF Ethernet profile

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]

Date: Wed, 17 Jan 2024 18:04:56 -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 Tue, 16 Jan 2024 23:37:28 -0800 Saeed Mahameed wrote:
> On 08 Jan 18:58, Jakub Kicinski wrote:
> >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.  
> 
> AFAIK it is not implemented via "stealing" from esw, esw is completely
> managed by driver, FW has no access to it, the management PF completely
> bypasses eswitch to talk to BMC in ConnectX arch.
> 
> 
>     ┌─────────────┐            ┌─────────────┐
>     │             │            │             │
>     │             │            │            ┌┼────────────┐
>     │     ┌───────┼────────────┼────────────┼│ mgmt PF    │
>     │  BMC│       │ NC-SI      │   ConnectX └┼────────────┘
>     │     │       │◄──────────►│             │
>     │     │       │      ^     │     NIC     │
>     │     │       │      |     │            ┌┼────────────┐
>     │     │       │      |     │      ┌─────┼│ PF         │
>     │     │       │      |     │      │     └┼────────────┘
>     │     │       │      |     │      │      │
>     └─────▼───────┘      |     └──────▼──────┘
>           │phy           /            │ phy
>           │             /             │
>           ▼            /              ▼
>       Management      /              Network
>         Network      /
                      /
                     /
What are the two lines here?

Are there really two connections / a separate MAC that's
not the NC-SI one?

Or is rhe BMC is configured to bridge / forward between NC-SI 
and the port?

Or the pass-thru packets are somehow encapsulated over the NC-SI MAC?