Re: [PATCH v6 2/2] mctp pcc: Implement MCTP over PCC Transport

From: Adam Young
Date: Thu Oct 31 2024 - 11:51:40 EST


We need a hardware address to create a socket without an EID in order to know where we are sending the packets.

The Hardware addressing is needed to be able to use the device in point-to-point mode.  It is possible to have multiple devices at the hardware level, and also to not use EID based routing.  Thus, the kernel needs to expose which device is which.  The Essential piece of information is the outbox, which identifies which channel the  message will be sent on.  The inbox is in the hardware address as well as a confirmation of on which channel the messages are expected to return. In the future, it is possible to reuse channels and IRQs in constrained situations, and the driver would then be able to deduce from the packet which remote device sent it.

Probably not correct to say the  there is no hardware addressing on the packet.  Instead, there is a portion of it on outgoing packets, and a different portion on incoming packets.

The hardware address format is in an upcoming version of the spec not yet published.

The namespace is for future expansion.  I expect this to always be 0.

I'll fix the other review corrections shortly.


On 10/30/24 21:28, Jeremy Kerr wrote:
I recall querying this in v1, not sure if there was a response, but:

Given there is no hardware addressing in the packet format, what is the
meaning of the physical address on the interface? It's a little strange
to define a hardware address here that isn't used for actual addressing.

For point-to-point links like this (and the serial transport), it's fine
to have no hw address on the device.

If this is purely local-machine-specific instance data, I suspect that
this belongs elsewhere. A read-only sysfs attribute could work?