netdev - Re: [PATCH] net: mctp: Add MCTP PCIe VDM transport driver

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: <5182407d-c252-403a-bb62-ebd11b0f126a@amperemail.onmicrosoft.com>
Date: Fri, 18 Jul 2025 12:48:30 +0700
From: Khang D Nguyen <khangng@...eremail.onmicrosoft.com>
To: Jeremy Kerr <jk@...econstruct.com.au>, YH Chung
 <yh_chung@...eedtech.com>,
 "matt@...econstruct.com.au" <matt@...econstruct.com.au>,
 "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
 "davem@...emloft.net" <davem@...emloft.net>,
 "edumazet@...gle.com" <edumazet@...gle.com>,
 "kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com"
 <pabeni@...hat.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 BMC-SW <BMC-SW@...eedtech.com>
Cc: Hieu Le <lhieu@...amperecomputing.com>
Subject: Re: [PATCH] net: mctp: Add MCTP PCIe VDM transport driver

Hi YH and Jeremy,

[+CC Hieu]

>> Could you share if there's any preliminary prototype or idea for the
>> format of the lladdr that core plans to implement, particularly
>> regarding how the route type should be encoded or parsed?
> 
> Excellent question! I suspect we would want a four-byte representation,
> being:
> 
>   [0]: routing type (bits 0:2, others reserved)
>   [1]: segment (or 0 for non-flit mode)
>   [2]: bus
>   [3]: device / function
> 
> which assumes there is some value in combining formats between flit- and
> non-flit modes. I am happy to adjust if there are better ideas.
> 
> Khang: any inputs from your side there?

I believe segment 0 is a common valid segment and is not reserved. If we 
want to combine, we might need another bit in the first byte to 
represent if it is flit-mode or not. But I am not sure if it is worth 
the effort, rather than just separate them.

As far as I understand, I think we have been discussing the address 
format for each "Transport Binding" (e.g, I2C vs PCIe-VDM vs ...).

According to DSP0239, I suggest we should decide the lladdr format based 
on the more precise "Physical Medium Identifier" (e.g, PCIe 5.0 or PCIe 
6.0 non-Flit or PCIe 6.0 Flit Mode), rather than the more general 
"Physical Transport Binding Identifier". The specification seems to 
suggest this by the wording "primarily".

     The identifier is primarily used to identify which physical
     addressing format is used for MCTP packets on the bus.

Transport Binding Identifier used to be enough, until they separate the 
address for PCIe-VDM non-Flit and Flit Mode. I am afraid if they add 
something new again, we might not be able to retrofit.

It should be safer and easier to get the format right for each Physical 
Medium Identifier, rather than for each Physical Transport Binding.

So my opinion:

- 3-byte for non-Flit (0x08-0x0E medium type)
   4-byte for Flit Mode (0x40 medium type)
- Drivers should be able to advertise their Physical Medium Identifier
   alongside the existing Physical Transport Binding Identifier.
- We can document a stable lladdr / Linux kernel physical format used
   for sockets for each Physical Medium Identifier, not Physical
   Transport Binding.

Sincerely,
Khang