From: Mukul Joshi <mukul.joshi@amd.com>
To: "Lazar, Lijo" <lijo.lazar@amd.com>, amd-gfx@lists.freedesktop.org
Cc: Felix.Kuehling@amd.com, Harish.Kasiviswanathan@amd.com,
philip.yang@amd.com
Subject: Re: [PATCHv2 4/8] drm/amdgpu: Attribute UALink loopback messages to the correct sender
Date: Wed, 28 Oct 2026 10:43:57 -0400 [thread overview]
Message-ID: <42ed2e2e-1e36-4deb-9825-a00cb42d110d@amd.com> (raw)
In-Reply-To: <18feb9ae-d755-4ad4-9dc5-7f80880a2991@amd.com>
On 10/28/2026 10:00 AM, Lazar, Lijo wrote:
>
>
> On 28-Oct-26 7:23 PM, Mukul Joshi wrote:
>>
>> On 10/28/2026 2:23 AM, Lazar, Lijo wrote:
>>>
>>>
>>> On 28-Oct-26 1:24 AM, Mukul Joshi wrote:
>>>> In UALink loopback mode a single GPU acts as both the exporter and the
>>>> importer, so the sender accel ID of a message depends on its
>>>> direction.
>>>>
>>>> - Send HELLO as the opposite role of the destination: a message to the
>>>> exporter is sent as the importer and vice versa. Outside loopback
>>>> this is still the GPU's own accel ID.
>>>>
>>>> - The MP nHT stamps the IH cookie of every HW-delivered message with
>>>> the GPU ID of the single physical station, the exporter. The
>>>> only HW
>>>> path is importer -> exporter, so attribute these messages to the
>>>> importer. SW-emulated exporter -> importer messages carry no IH
>>>> ring
>>>> and already name the exporter as the sender.
>>>>
>>>> Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
>>>> ---
>>>> v1->v2:
>>>> - Use ualink_exp_accel_id/ualink_imp_accel_id() wrappers in
>>>> amdgpu_ualink_process_irq(). (Lijo)
>>>>
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c | 32
>>>> +++++++++++++++++++++-
>>>> 1 file changed, 31 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c
>>>> index 6c70be7badec..96a6023f51c5 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c
>>>> @@ -1090,6 +1090,23 @@ static inline u32 ualink_imp_accel_id(struct
>>>> amdgpu_device *adev)
>>>> return adev->ualink.info->ppod.accel_id;
>>>> }
>>>> +/*
>>>> + * amdgpu_ualink_local_sender_accel_id - sender accel_id for an
>>>> outgoing message
>>>> + *
>>>> + * Normally a GPU sends messages as its own (single) accelerator. In
>>>> loopback
>>>> + * mode the same GPU plays both roles, so the sender identity
>>>> depends on the
>>>> + * destination: a message to the exporter is sent as the importer
>>>> and vice
>>>> + * versa. Outside loopback both roles collapse to the GPU's own
>>>> accel_id.
>>>> + */
>>>> +static u32 amdgpu_ualink_local_sender_accel_id(struct amdgpu_device
>>>> *adev,
>>>> + u32 remote_acc_id)
>>>> +{
>>>> + if (remote_acc_id == ualink_exp_accel_id(adev))
>>>
>>> +#define AMDGPU_UALINK_LOOPBACK_EXPORTER_ACCID 1
>>>
>>> 1 is a possible id in a regular vpod config also. I think a check of
>>> loopback mode also is required here.
>>
>> We check loopback mode inside the helper, ualink_exp_accel_id().
>>
>
> Thanks for clarifying. Adding a check may be a bit easier to read.
>
> if (!loopback_mode)
> return adev->ualink.info->ppod.accel_id;
>
The wrappers are handling all this in one place, because we need same
check for imp_accel_id as well.
So, better to keep them in one place I think.
Thanks,
Mukul
> Thanks,
> Lijo
>
>> Thanks,
>>
>> Mukul
>>
>>>
>>> Thanks,
>>> Lijo
>>>
>>>> + return ualink_imp_accel_id(adev);
>>>> +
>>>> + return ualink_exp_accel_id(adev);
>>>> +}
>>>> +
>>>> static bool amdgpu_ualink_is_local_accel(struct amdgpu_device
>>>> *adev,
>>>> u32 accel_id)
>>>> {
>>>> @@ -2238,7 +2255,10 @@ static int amdgpu_ualink_send_hello_msg(struct
>>>> amdgpu_device *adev,
>>>> dw0 = AMDGPU_UALINK_HELLO_MSG;
>>>> dw0 |= (remote_acc_id <<
>>>> AMDGPU_UALINK_HELLO_MSG_RECV_ACCID_SHIFT);
>>>> - dw0 |= (adev->ualink.info->ppod.accel_id <<
>>>> + /* In loopback the sender is the opposite role of the
>>>> destination, so
>>>> + * the exporter side tracks the connection under the importer
>>>> accel_id.
>>>> + */
>>>> + dw0 |= (amdgpu_ualink_local_sender_accel_id(adev,
>>>> remote_acc_id) <<
>>>> AMDGPU_UALINK_HELLO_MSG_SENDER_ACCID_SHIFT);
>>>> dev_dbg(adev->dev, "SEND HELLO: HELLO message to remote
>>>> AccId:%u\n",
>>>> @@ -6548,6 +6568,16 @@ static int amdgpu_ualink_process_irq(struct
>>>> amdgpu_device *adev,
>>>> return handled;
>>>> }
>>>> + /* UALink loopback: the MP nHT stamps every HW-delivered
>>>> message with
>>>> + * the GPU ID of the single physical station, the exporter. The
>>>> only
>>>> + * HW path is importer -> exporter, so the real sender is the
>>>> importer.
>>>> + * SW-emulated exporter -> importer messages carry no IH ring and
>>>> + * already name the exporter as sender.
>>>> + */
>>>> + if (adev->ualink.loopback.enabled && entry->ih &&
>>>> + src_acc_id == ualink_exp_accel_id(adev))
>>>> + src_acc_id = ualink_imp_accel_id(adev);
>>>> +
>>>> msg_type = dw0 & AMDGPU_UALINK_MESSAGE_HEADER_MASK;
>>>> local_acc_id = adev->ualink.info->ppod.accel_id;
>>>> dev_dbg(adev->dev, "Got MSG: remote acc_id %u msg_type %u\n",
>>>
>
next prev parent reply other threads:[~2026-10-28 14:44 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 19:54 [PATCHv2 0/8] Add UALink Loopback support Mukul Joshi
2026-10-27 19:54 ` [PATCHv2 1/8] drm/amdgpu: Add UALink loopback infrastructure Mukul Joshi
2026-10-27 20:22 ` Felix Kuehling
2026-10-27 20:45 ` Mukul Joshi
2026-10-27 20:56 ` Felix Kuehling
2026-10-28 6:06 ` Lazar, Lijo
2026-10-27 19:54 ` [PATCHv2 2/8] drm/amdgpu: Support VMID 0 GPUVA completion WB address for UALink Mukul Joshi
2026-10-27 21:23 ` Felix Kuehling
2026-10-27 19:54 ` [PATCHv2 3/8] drm/amdgpu: Emulate exporter->importer UALink messages in loopback Mukul Joshi
2026-10-27 21:34 ` Felix Kuehling
2026-10-27 19:54 ` [PATCHv2 4/8] drm/amdgpu: Attribute UALink loopback messages to the correct sender Mukul Joshi
2026-10-27 21:38 ` Felix Kuehling
2026-10-28 6:23 ` Lazar, Lijo
2026-10-28 13:53 ` Mukul Joshi
2026-10-28 14:00 ` Lazar, Lijo
2026-10-28 14:43 ` Mukul Joshi [this message]
2026-10-27 19:54 ` [PATCHv2 5/8] drm/amdgpu: Set up UALink rings and metadata for loopback Mukul Joshi
2026-10-27 20:20 ` Felix Kuehling
2026-10-27 19:54 ` [PATCHv2 6/8] drm/amdgpu: Enable UALink loopback mode Mukul Joshi
2026-10-27 21:45 ` Felix Kuehling
2026-10-28 6:33 ` Lazar, Lijo
2026-10-27 19:54 ` [PATCHv2 7/8] drm/amdgpu: Reject config updates in " Mukul Joshi
2026-10-27 21:06 ` Felix Kuehling
2026-10-27 19:54 ` [PATCHv2 8/8] drm/amdgpu: Temporarily enable UALink loopback via module parameter Mukul Joshi
2026-10-27 21:47 ` Felix Kuehling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42ed2e2e-1e36-4deb-9825-a00cb42d110d@amd.com \
--to=mukul.joshi@amd.com \
--cc=Felix.Kuehling@amd.com \
--cc=Harish.Kasiviswanathan@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=lijo.lazar@amd.com \
--cc=philip.yang@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.