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: <59d6a0ee7f47346d8beb0283ee79a493c76dbb45.camel@codeconstruct.com.au>
Date: Fri, 18 Jul 2025 14:03:58 +0800
From: Jeremy Kerr <jk@...econstruct.com.au>
To: Khang D Nguyen <khangng@...eremail.onmicrosoft.com>, 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 Khang,

Thanks for the input, I appreciate it.

> > Khang: any inputs from your side there?
> 
> I believe segment 0 is a common valid segment and is not reserved.

0 would not have a special meaning in flit mode (ie, when we're using
the segment number); this was more a reference to being optional in
non-flit mode.

> 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.

Yep, had the same line of thinking here too.

I agree that it would make sense to have the address format reflect the
actual hardware transport. Having variation across the binding
identifier should not be a problem.

> 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.

Agreed, sounds like a good plan. I'll look at options for the physical
medium identifier.

YH: so we would just have the three-byte format for your proposed
driver:

   [0]: routing type (bits 0:2, others reserved)
   [1]: bus
   [2]: device / function

- assuming you're only handling non-flit mode for now.

Cheers,


Jeremy