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>,
	Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [PATCH v2 03/17] drm/xe/pf: Add _locked variants of the VF EQ config functions
Date: Thu, 30 Oct 2025 20:47:51 +0100	[thread overview]
Message-ID: <a6a09383-da82-42d7-8ac3-e8de31d6ec87@intel.com> (raw)
In-Reply-To: <20251029084707.htvoaxto2ul7axjk@intel.com>



On 10/29/2025 9:47 AM, Piotr Piórkowski wrote:
> Michal Wajdeczko <michal.wajdeczko@intel.com> wrote on wto [2025-paź-28 18:58:17 +0100]:
>> In upcoming patches we will want to configure VF's execution
>> quantum (EQ) on all GTs under single lock to avoid potential
>> races in parallel GT configuration attempts.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> ---
>>  drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c | 58 +++++++++++++++++-----
>>  drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h |  4 ++
>>  2 files changed, 49 insertions(+), 13 deletions(-)
>>
>> 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 c0c0215c0703..717f81e76b8c 100644
>> --- a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
>> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
>> @@ -1732,29 +1732,65 @@ static int pf_get_exec_quantum(struct xe_gt *gt, unsigned int vfid)
>>  }
>>  
>>  /**
>> - * xe_gt_sriov_pf_config_set_exec_quantum - Configure execution quantum for the VF.
>> + * xe_gt_sriov_pf_config_set_exec_quantum_locked() - Configure execution quantum of the VF.
>>   * @gt: the &xe_gt
>>   * @vfid: the VF identifier
>>   * @exec_quantum: requested execution quantum in milliseconds (0 is infinity)
>>   *
>> - * This function can only be called on PF.
>> + * This function can only be called on PF with the master mutex hold.
>> + * It will log the provisioned value or an error in case of the failure.
>>   *
>>   * Return: 0 on success or a negative error code on failure.
>>   */
>> -int xe_gt_sriov_pf_config_set_exec_quantum(struct xe_gt *gt, unsigned int vfid,
>> -					   u32 exec_quantum)
>> +int xe_gt_sriov_pf_config_set_exec_quantum_locked(struct xe_gt *gt, unsigned int vfid,
>> +						  u32 exec_quantum)
>>  {
>>  	int err;
>>  
>> -	mutex_lock(xe_gt_sriov_pf_master_mutex(gt));
>> +	lockdep_assert_held(xe_gt_sriov_pf_master_mutex(gt));
>> +
>>  	err = pf_provision_exec_quantum(gt, vfid, exec_quantum);
>> -	mutex_unlock(xe_gt_sriov_pf_master_mutex(gt));
>>  
>>  	return pf_config_set_u32_done(gt, vfid, exec_quantum,
>> -				      xe_gt_sriov_pf_config_get_exec_quantum(gt, vfid),
>> +				      pf_get_exec_quantum(gt, vfid),
>>  				      "execution quantum", exec_quantum_unit, err);
>>  }
>>  
>> +/**
>> + * xe_gt_sriov_pf_config_set_exec_quantum - Configure execution quantum for the VF.
>> + * @gt: the &xe_gt
>> + * @vfid: the VF identifier
>> + * @exec_quantum: requested execution quantum in milliseconds (0 is infinity)
>> + *
>> + * This function can only be called on PF.
>> + * It will log the provisioned value or na error in case of the failure.
> 
> typo: na -> an
>> + *
>> + * Return: 0 on success or a negative error code on failure.
>> + */
>> +int xe_gt_sriov_pf_config_set_exec_quantum(struct xe_gt *gt, unsigned int vfid,
>> +					   u32 exec_quantum)
>> +{
>> +	guard(mutex)(xe_gt_sriov_pf_master_mutex(gt));
>> +
>> +	return xe_gt_sriov_pf_config_set_exec_quantum_locked(gt, vfid, exec_quantum);
>> +}
>> +
>> +/**
>> + * xe_gt_sriov_pf_config_get_exec_quantum_locked() - Get VF's execution quantum.
>> + * @gt: the &xe_gt
>> + * @vfid: the VF identifier
>> + *
>> + * This function can only be called on PF with the master mutex hold.
>> + *
>> + * Return: VF's (or PF's) execution quantum in milliseconds.
>> + */
>> +u32 xe_gt_sriov_pf_config_get_exec_quantum_locked(struct xe_gt *gt, unsigned int vfid)
>> +{
>> +	lockdep_assert_held(xe_gt_sriov_pf_master_mutex(gt));
>> +
>> +	return pf_get_exec_quantum(gt, vfid);
> 
> NIT: Perhaps it would have been better to be consistent and call it the locked version here.

almost all static functions in this file are expecting lock to be
already taken, also enforced with lockdep_assert_held, and we use
_locked suffix only public functions (as those usually are _not_
expecting the lock)

> 
>> +}
>> +
>>  /**
>>   * xe_gt_sriov_pf_config_get_exec_quantum - Get VF's execution quantum.
>>   * @gt: the &xe_gt
>> @@ -1766,13 +1802,9 @@ int xe_gt_sriov_pf_config_set_exec_quantum(struct xe_gt *gt, unsigned int vfid,
>>   */
>>  u32 xe_gt_sriov_pf_config_get_exec_quantum(struct xe_gt *gt, unsigned int vfid)
>>  {
>> -	u32 exec_quantum;
>> +	guard(mutex)(xe_gt_sriov_pf_master_mutex(gt));
>>  
>> -	mutex_lock(xe_gt_sriov_pf_master_mutex(gt));
>> -	exec_quantum = pf_get_exec_quantum(gt, vfid);
>> -	mutex_unlock(xe_gt_sriov_pf_master_mutex(gt));
>> -
>> -	return exec_quantum;
>> +	return pf_get_exec_quantum(gt, vfid);
>>  }
>>  
>>  static const char *preempt_timeout_unit(u32 preempt_timeout)
>> diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h
>> index 513e6512a575..b4beb5a97031 100644
>> --- a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h
>> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h
>> @@ -40,6 +40,10 @@ int xe_gt_sriov_pf_config_bulk_set_lmem(struct xe_gt *gt, unsigned int vfid, uns
>>  u32 xe_gt_sriov_pf_config_get_exec_quantum(struct xe_gt *gt, unsigned int vfid);
>>  int xe_gt_sriov_pf_config_set_exec_quantum(struct xe_gt *gt, unsigned int vfid, u32 exec_quantum);
>>  
>> +u32 xe_gt_sriov_pf_config_get_exec_quantum_locked(struct xe_gt *gt, unsigned int vfid);
>> +int xe_gt_sriov_pf_config_set_exec_quantum_locked(struct xe_gt *gt, unsigned int vfid,
>> +						  u32 exec_quantum);
>> +
>>  u32 xe_gt_sriov_pf_config_get_preempt_timeout(struct xe_gt *gt, unsigned int vfid);
>>  int xe_gt_sriov_pf_config_set_preempt_timeout(struct xe_gt *gt, unsigned int vfid,
>>  					      u32 preempt_timeout);
> 
> but anyway it looks good:
> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>

thanks!

> 
>> -- 
>> 2.47.1
>>
> 


  parent reply	other threads:[~2025-10-30 19:47 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-28 17:58 [PATCH v2 00/17] PF: Add sriov_admin sysfs tree Michal Wajdeczko
2025-10-28 17:58 ` [PATCH v2 01/17] drm/xe/pf: Prepare sysfs for SR-IOV admin attributes Michal Wajdeczko
2025-10-28 17:58 ` [PATCH v2 02/17] drm/xe/pf: Take RPM during calls to SR-IOV attr.store() Michal Wajdeczko
2025-10-28 17:58 ` [PATCH v2 03/17] drm/xe/pf: Add _locked variants of the VF EQ config functions Michal Wajdeczko
2025-10-29  8:47   ` Piotr Piórkowski
2025-10-29  9:00     ` Piotr Piórkowski
2025-10-30 19:47     ` Michal Wajdeczko [this message]
2025-10-28 17:58 ` [PATCH v2 04/17] drm/xe/pf: Add _locked variants of the VF PT " Michal Wajdeczko
2025-10-29 11:00   ` Piotr Piórkowski
2025-10-29 20:27   ` Lucas De Marchi
2025-10-28 17:58 ` [PATCH v2 05/17] drm/xe/pf: Allow change PF and VFs EQ/PT using sysfs Michal Wajdeczko
2025-10-29 11:17   ` Piotr Piórkowski
2025-10-29 20:26   ` Lucas De Marchi
2025-10-28 17:58 ` [PATCH v2 06/17] drm/xe/pf: Relax report helper to accept PF in bulk configs Michal Wajdeczko
2025-10-28 17:58 ` [PATCH v2 07/17] drm/xe/pf: Fix signature of internal config helpers Michal Wajdeczko
2025-10-29  8:02   ` Piotr Piórkowski
2025-10-28 17:58 ` [PATCH v2 08/17] drm/xe/pf: Add functions to bulk configure EQ/PT on GT Michal Wajdeczko
2025-10-29 13:59   ` Piotr Piórkowski
2025-10-29 20:32   ` Lucas De Marchi
2025-10-28 17:58 ` [PATCH v2 09/17] drm/xe/pf: Add functions to bulk provision EQ/PT Michal Wajdeczko
2025-10-29 20:33   ` Lucas De Marchi
2025-10-28 17:58 ` [PATCH v2 10/17] drm/xe/pf: Allow bulk change all VFs EQ/PT using sysfs Michal Wajdeczko
2025-10-28 17:58 ` [PATCH v2 11/17] drm/xe/pf: Add functions to provision scheduling priority Michal Wajdeczko
2025-10-28 17:58 ` [PATCH v2 12/17] drm/xe/pf: Allow bulk change all VFs priority using sysfs Michal Wajdeczko
2025-10-30 12:43   ` Lucas De Marchi
2025-10-30 13:47     ` Lucas De Marchi
2025-10-28 17:58 ` [PATCH v2 13/17] drm/xe/pf: Allow change PF scheduling " Michal Wajdeczko
2025-10-30 13:35   ` Lucas De Marchi
2025-10-30 13:49     ` Lucas De Marchi
2025-10-28 17:58 ` [PATCH v2 14/17] drm/xe/pf: Promote xe_pci_sriov_get_vf_pdev Michal Wajdeczko
2025-10-28 17:58 ` [PATCH v2 15/17] drm/xe/pf: Add sysfs device symlinks to enabled VFs Michal Wajdeczko
2025-10-30 13:40   ` Lucas De Marchi
2025-10-28 17:58 ` [PATCH v2 16/17] drm/xe/pf: Allow to stop and reset VF using sysfs Michal Wajdeczko
2025-10-30  8:45   ` Piotr Piórkowski
2025-10-30 13:43   ` Lucas De Marchi
2025-10-30 13:50     ` Michal Wajdeczko
2025-10-30 14:14       ` Lucas De Marchi
2025-10-28 17:58 ` [PATCH v2 17/17] drm/xe/pf: Add documentation for sriov_admin attributes Michal Wajdeczko
2025-10-30 17:25   ` Lucas De Marchi
2025-10-31 12:35     ` Michal Wajdeczko
2025-10-28 20:04 ` ✗ CI.checkpatch: warning for PF: Add sriov_admin sysfs tree (rev2) Patchwork
2025-10-28 20:05 ` ✓ CI.KUnit: success " Patchwork
2025-10-28 20:43 ` ✓ Xe.CI.BAT: " Patchwork
2025-10-29  7:15 ` ✗ Xe.CI.Full: failure " Patchwork
2025-10-29 10:11   ` Michal Wajdeczko

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=a6a09383-da82-42d7-8ac3-e8de31d6ec87@intel.com \
    --to=michal.wajdeczko@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --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