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

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

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