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

[Jeremy Kerr <jk@codeconstruct.com.au>]

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