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]

Message-ID: <ZaeDuDSVFs46JffL@x130>
Date: Tue, 16 Jan 2024 23:37:28 -0800
From: Saeed Mahameed <saeed@...nel.org>
To: Jakub Kicinski <kuba@...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 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