Message-ID: <7c1de9a0-9d82-4369-bdb1-63c110d81194@amperemail.onmicrosoft.com>
Date: Wed, 13 Nov 2024 13:41:50 -0500
From: Adam Young <admiyo@...eremail.onmicrosoft.com>
To: Jeremy Kerr <jk@...econstruct.com.au>, admiyo@...amperecomputing.com,
 Matt Johnston <matt@...econstruct.com.au>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 Sudeep Holla <sudeep.holla@....com>,
 Jonathan Cameron <Jonathan.Cameron@...wei.com>,
 Huisong Li <lihuisong@...wei.com>
Subject: Re: [PATCH v6 2/2] mctp pcc: Implement MCTP over PCC Transport


On 11/11/24 20:00, Jeremy Kerr wrote:
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.]
>
>
> Hi Adam,
>> "The PCC signature. The signature of a subspace is computed by a
>> bitwise-or of the value 0x50434300 with the subspace ID. For example,
>> subspace 3 has the signature 0x50434303."
>>
>> This could be used, but the inclusion of the "PCC" is unnecessary, as
>> it is on every packet.  Thus only the subspace ID is relevant. This
>> is the  index of the  entry in the PCCT, and is what I have been
>> calling the  outbox ID. Thus it is half of the address that I am
>> proposing.
> But the signature value isn't implementing any MCTP-bus addressing
> functionality, right? It's a fixed value that has to be set the same
> way on all transactions using that PCC channel.
>
> Just to walk it back a bit, we have two possible interpretations here:
>
>   1) that the channel indexes *do* form something like a physical
>      addressing mechanism; when packets are sent over a channel to a
>      remote endpoint, we need to add a specific channel identifier.
>
>   2) that the channel indices are more of an internal detail of the
>      transport mechanism: they're identifying channels, not MCTP
>      endpoints (kinda like setting the PCIe target address when
>      transmitting a network packet, perhaps?)
>
> If we adopt the (1) approach, we'd want a hardware address to represent
> the mechanism for addressing an MCTP endpoint, not an interface
> instance. That would end up with something along the lines of:
>
>   - MCTP-over-PCC hardware addresses would be a single byte (to contain a
>     channel ID)
>
>   - the interface would have a hardware address of just the inbox ID:
>     incoming packets are received via the inbox to the local interface,
>     and so are "addressed" to that inbox ID
>
>   - remote endpoints would be represented by a hardware address of just
>     the outbox ID: outgoing packets are sent via the outbox to the remote
>     endpoint, so are "addressed" to that outbox ID
>
> ... but that doesn't seem to be the approach you want to take here, as
> it doesn't match your requirements for an interface lladdr (also,
> implementing the neighbour-handling infrastructure for that would seem
> to be overkill for a strictly peer-to-peer link type).
>
> So a couple of queries to get us to a decision:
>
> Your goal with exposing the channel numbers is more to choose the
> correct *local* interface to use on a system, right? Can you elaborate
> on your objections for using something like sysfs attributes for that?
>
> Can you outline the intended usage of the spec updates that would add
> the address format you mentioned? Is there a use-case we need to
> consider for those?

On consideration that the spec is still closed, and may change between 
now and when it is published, I am going to pull out the hardware 
address from this patch.  Once we have a public spec, we can implement 
it without fear of breaking userland.




>
> Cheers,
>
>
> Jeremy

Powered by blists - more mailing lists