[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <675c2760e1ed64ee8e8bcd82c74af764d48fea6c.camel@codeconstruct.com.au>
Date: Fri, 01 Nov 2024 16:55:35 +0800
From: Jeremy Kerr <jk@...econstruct.com.au>
To: Adam Young <admiyo@...eremail.onmicrosoft.com>,
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
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
Powered by blists - more mailing lists