Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 = &gt->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
>>
> 


  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