Re: [PATCH v6 2/2] mctp pcc: Implement MCTP over PCC Transport
From: Jeremy Kerr
Date: Fri Nov 01 2024 - 04:55:56 EST
Hi Adam,
Thanks for the quick response. I think the dev lladdr is the main thing
to work out here, and it's not something we can change that post-merge.
I'm not yet convinced on your current approach, but a few
comments/queries that may help us get a consensus there, one way or the
other:
> We need a hardware address to create a socket without an EID in order
> to know where we are sending the packets.
Just to clarify that: for physical (ie, null-EID) addressing, you don't
need the hardware address, you need:
1) the outgoing interface's ifindex; and
2) the hardware address of the *remote* endpoint, in whatever
format is appropriate for link type
In cases where there is no hardware addressing in the tx packet (which
looks to apply to PCC), (2) is empty.
I understand that you're needing some mechanism for finding the correct
ifindex, but I don't think using the device lladdr is the correct
approach.
We have this model already for mctp-over-serial, which is another
point-to-point link type. MCTP-over-serial devices have no hardware
address, as there is no hardware addressing in the packet format. In
EID-less routing, it's up to the application to determine the ifindex,
using whatever existing device-identification mechanism is suitable.
> 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.
Yes, that's totally fine to expect find a specific device - but the
device's hardware address is not the conventional place to do that.
> 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.
Those are the indices of the shared memory regions used for the
transfer, right?
> 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.
The spec mentions:
A single PCC instance shall serve as a communication channel
between at most two MCTP capable entities
so how is it ambiguous which remote device has sent a packet? Am I
misinterpreting "channel" there?
In which case, how does the driver RX path do that deduction? There is
no hardware addressing information in the DSP0292 packet format.
> 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.
I can't really comment on non-published specs, but that looks more like
identifiers for the tx/rx channel pair (ie., maps to a device
identifier) rather than physical packet addressing data (ie., an
interface lladdr). Happy to be corrected on that though!
Cheers,
Jeremy