From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: "Piotr Piórkowski" <piotr.piorkowski@intel.com>
Cc: <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH 1/3] drm/xe/pf: Use migration-friendly context IDs auto-provisioning
Date: Thu, 6 Nov 2025 17:55:09 +0100 [thread overview]
Message-ID: <53319edf-7255-4f11-a36a-dfbe171aaca1@intel.com> (raw)
In-Reply-To: <20251106142455.juyvarn3wqqa43ld@intel.com>
On 11/6/2025 3:24 PM, Piotr Piórkowski wrote:
> Michal Wajdeczko <michal.wajdeczko@intel.com> wrote on śro [2025-lis-05 19:32:50 +0100]:
>> Instead of trying very hard to find the largest fair number of GuC
>> context IDs that could be allocated for VFs on the current GT, pick
>> some smaller rounded down to power-of-two value that is more likely
>> to be provisioned in the same manner by the other PF instance:
>>
>> num VFs | num contexts
>> --------+-------------
>> 63..32 | 1024
>> 31..16 | 2048
>> 15..8 | 4096
>> 7..4 | 8192
>> 3..2 | 16384
>> 1 | 32768 (regular PF)
>> 1 | 64512 (admin only PF)
>>
>> Add also helper function to determine if the PF is admin-only,
>> and for now use .probe_display flag for that.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c | 16 ++++++++++++++++
>> drivers/gpu/drm/xe/xe_sriov_pf_helpers.h | 11 +++++++++++
>> 2 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
>> index d90261a7ab7c..14feda215d5b 100644
>> --- a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
>> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
>> @@ -985,6 +985,16 @@ int xe_gt_sriov_pf_config_bulk_set_ctxs(struct xe_gt *gt, unsigned int vfid,
>> "GuC context IDs", no_unit, n, err);
>> }
>>
>> +static u32 pf_profile_fair_ctxs(struct xe_gt *gt, unsigned int num_vfs)
>> +{
>> + bool admin_only_pf = xe_sriov_pf_admin_only(gt_to_xe(gt));
>> +
>> + if (admin_only_pf && num_vfs == 1)
>> + return ALIGN_DOWN(GUC_ID_MAX, SZ_1K);
>> +
>> + return rounddown_pow_of_two(GUC_ID_MAX / num_vfs);
>> +}
>> +
>> static u32 pf_estimate_fair_ctxs(struct xe_gt *gt, unsigned int num_vfs)
>> {
>> struct xe_guc_id_mgr *idm = >->uc.guc.submission_state.idm;
>> @@ -1017,6 +1027,7 @@ static u32 pf_estimate_fair_ctxs(struct xe_gt *gt, unsigned int num_vfs)
>> int xe_gt_sriov_pf_config_set_fair_ctxs(struct xe_gt *gt, unsigned int vfid,
>> unsigned int num_vfs)
>> {
>> + u32 profile = pf_profile_fair_ctxs(gt, num_vfs);
>> u32 fair;
>>
>> xe_gt_assert(gt, vfid);
>> @@ -1029,6 +1040,11 @@ int xe_gt_sriov_pf_config_set_fair_ctxs(struct xe_gt *gt, unsigned int vfid,
>> if (!fair)
>> return -ENOSPC;
>>
>> + fair = min(fair, profile);
>> + if (fair < profile)
>> + xe_gt_sriov_info(gt, "Using non-profile provisioning (%s %u vs %u)\n",
>> + "GuC context IDs", fair, profile);
>> +
>> return xe_gt_sriov_pf_config_bulk_set_ctxs(gt, vfid, num_vfs, fair);
>> }
>>
>> diff --git a/drivers/gpu/drm/xe/xe_sriov_pf_helpers.h b/drivers/gpu/drm/xe/xe_sriov_pf_helpers.h
>> index 4a4340fb633a..3ddeba4451cd 100644
>> --- a/drivers/gpu/drm/xe/xe_sriov_pf_helpers.h
>> +++ b/drivers/gpu/drm/xe/xe_sriov_pf_helpers.h
>> @@ -48,6 +48,17 @@ static inline unsigned int xe_sriov_pf_num_vfs(const struct xe_device *xe)
>> return pci_num_vf(to_pci_dev(xe->drm.dev));
>> }
>>
>> +/**
>> + * xe_sriov_pf_admin_only() - Check if PF is mainly used for VFs administration.
>> + * @xe: the PF &xe_device
>> + *
>> + * Return: True if PF is mainly used for VFs administration.
>> + */
>> +static inline bool xe_sriov_pf_admin_only(const struct xe_device *xe)
>> +{
>> + return !xe->info.probe_display;
>> +}
>
> Honestly, I'm not entirely convinced by this condition for pf_admin_only.
> I wonder if we shouldn't set it up differently, e.g., through a dedicated
> parameter.
yes, that's exactly the plan (but it's on my TODO list and I needed something
sooner, and logic that uses .probe_display shall be correct in 99% cases)
> But for now, I don't think it bothers us too much:
> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
thanks!
>
>> +
>> static inline struct mutex *xe_sriov_pf_master_mutex(struct xe_device *xe)
>> {
>> xe_assert(xe, IS_SRIOV_PF(xe));
>> --
>> 2.47.1
>>
>
next prev parent reply other threads:[~2025-11-06 16:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-05 18:32 [PATCH 0/3] PF: migration-friendly auto-provisioning Michal Wajdeczko
2025-11-05 18:32 ` [PATCH 1/3] drm/xe/pf: Use migration-friendly context IDs auto-provisioning Michal Wajdeczko
2025-11-06 14:24 ` Piotr Piórkowski
2025-11-06 16:55 ` Michal Wajdeczko [this message]
2025-11-05 18:32 ` [PATCH 2/3] drm/xe/pf: Use migration-friendly doorbells auto-provisioning Michal Wajdeczko
2025-11-06 14:39 ` Piotr Piórkowski
2025-11-05 18:32 ` [PATCH 3/3] drm/xe/tests: Add KUnit tests for PF fair provisioning Michal Wajdeczko
2025-11-06 16:09 ` Piotr Piórkowski
2025-11-06 16:59 ` [PATCH v2 " Michal Wajdeczko
2025-11-05 21:28 ` ✗ CI.checkpatch: warning for PF: migration-friendly auto-provisioning Patchwork
2025-11-05 21:30 ` ✓ CI.KUnit: success " Patchwork
2025-11-05 22:46 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-11-06 9:50 ` ✗ Xe.CI.Full: " Patchwork
2025-11-06 17:13 ` ✗ CI.checkpatch: warning for PF: migration-friendly auto-provisioning (rev2) Patchwork
2025-11-06 17:15 ` ✓ CI.KUnit: success " Patchwork
2025-11-06 17:53 ` ✓ Xe.CI.BAT: " Patchwork
2025-11-07 14:52 ` ✗ Xe.CI.Full: failure " Patchwork
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=53319edf-7255-4f11-a36a-dfbe171aaca1@intel.com \
--to=michal.wajdeczko@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=piotr.piorkowski@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox