[Intel-gfx] [PATCH 04/47] drm/i915/guc: Add non blocking CTB send function

Michal Wajdeczko michal.wajdeczko at intel.com
Thu Jun 24 17:02:18 UTC 2021



On 24.06.2021 17:49, Matthew Brost wrote:
> On Thu, Jun 24, 2021 at 04:48:32PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 24.06.2021 09:04, Matthew Brost wrote:
>>> Add non blocking CTB send function, intel_guc_send_nb. GuC submission
>>> will send CTBs in the critical path and does not need to wait for these
>>> CTBs to complete before moving on, hence the need for this new function.
>>>
>>> The non-blocking CTB now must have a flow control mechanism to ensure
>>> the buffer isn't overrun. A lazy spin wait is used as we believe the
>>> flow control condition should be rare with a properly sized buffer.
>>>
>>> The function, intel_guc_send_nb, is exported in this patch but unused.
>>> Several patches later in the series make use of this function.
>>>
>>> Signed-off-by: John Harrison <John.C.Harrison at Intel.com>
>>> Signed-off-by: Matthew Brost <matthew.brost at intel.com>
>>> ---
>>>  drivers/gpu/drm/i915/gt/uc/intel_guc.h    | 12 +++-
>>>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 77 +++++++++++++++++++++--
>>>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  3 +-
>>>  3 files changed, 82 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>>> index 4abc59f6f3cd..24b1df6ad4ae 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>>> @@ -74,7 +74,15 @@ static inline struct intel_guc *log_to_guc(struct intel_guc_log *log)
>>>  static
>>>  inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len)
>>>  {
>>> -	return intel_guc_ct_send(&guc->ct, action, len, NULL, 0);
>>> +	return intel_guc_ct_send(&guc->ct, action, len, NULL, 0, 0);
>>> +}
>>> +
>>> +#define INTEL_GUC_SEND_NB		BIT(31)
>>
>> hmm, this flag really belongs to intel_guc_ct_send() so it should be
>> defined as CTB flag near that function declaration
>>
> 
> I can move this up a few lines.
> 
>>> +static
>>> +inline int intel_guc_send_nb(struct intel_guc *guc, const u32 *action, u32 len)
>>> +{
>>> +	return intel_guc_ct_send(&guc->ct, action, len, NULL, 0,
>>> +				 INTEL_GUC_SEND_NB);
>>>  }
>>>  
>>>  static inline int
>>> @@ -82,7 +90,7 @@ intel_guc_send_and_receive(struct intel_guc *guc, const u32 *action, u32 len,
>>>  			   u32 *response_buf, u32 response_buf_size)
>>>  {
>>>  	return intel_guc_ct_send(&guc->ct, action, len,
>>> -				 response_buf, response_buf_size);
>>> +				 response_buf, response_buf_size, 0);
>>>  }
>>>  
>>>  static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> index a17215920e58..c9a65d05911f 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> @@ -3,6 +3,11 @@
>>>   * Copyright © 2016-2019 Intel Corporation
>>>   */
>>>  
>>> +#include <linux/circ_buf.h>
>>> +#include <linux/ktime.h>
>>> +#include <linux/time64.h>
>>> +#include <linux/timekeeping.h>
>>> +
>>>  #include "i915_drv.h"
>>>  #include "intel_guc_ct.h"
>>>  #include "gt/intel_gt.h"
>>> @@ -373,7 +378,7 @@ static void write_barrier(struct intel_guc_ct *ct)
>>>  static int ct_write(struct intel_guc_ct *ct,
>>>  		    const u32 *action,
>>>  		    u32 len /* in dwords */,
>>> -		    u32 fence)
>>> +		    u32 fence, u32 flags)
>>>  {
>>>  	struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
>>>  	struct guc_ct_buffer_desc *desc = ctb->desc;
>>> @@ -421,9 +426,13 @@ static int ct_write(struct intel_guc_ct *ct,
>>>  		 FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
>>>  		 FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
>>>  
>>> -	hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>>> -	      FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
>>> -			 GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
>>> +	hxg = (flags & INTEL_GUC_SEND_NB) ?
>>> +		(FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_EVENT) |
>>> +		 FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
>>> +			    GUC_HXG_EVENT_MSG_0_DATA0, action[0])) :
>>> +		(FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>>> +		 FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
>>> +			    GUC_HXG_REQUEST_MSG_0_DATA0, action[0]));
>>
>> or as we already switched to accept and return whole HXG messages in
>> guc_send_mmio() maybe we should do the same for CTB variant too and
>> instead of using extra flag just let caller to prepare proper HXG header
>> with HXG_EVENT type and then in CTB code just look at this type to make
>> decision which code path to use
>>
> 
> Not sure I follow. Anyways could this be done in a follow up by you if
> want this change.
>  
>> note that existing callers should not be impacted, as full HXG header
>> for the REQUEST message looks exactly the same as "action" code alone.
>>
>>>  
>>>  	CT_DEBUG(ct, "writing (tail %u) %*ph %*ph %*ph\n",
>>>  		 tail, 4, &header, 4, &hxg, 4 * (len - 1), &action[1]);
>>> @@ -498,6 +507,46 @@ static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
>>>  	return err;
>>>  }
>>>  
>>> +static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32 len_dw)
>>> +{
>>> +	struct guc_ct_buffer_desc *desc = ctb->desc;
>>> +	u32 head = READ_ONCE(desc->head);
>>> +	u32 space;
>>> +
>>> +	space = CIRC_SPACE(desc->tail, head, ctb->size);
>>> +
>>> +	return space >= len_dw;
>>
>> here you are returning true(1) as has room
>>
> 
> See below.
>  
>>> +}
>>> +
>>> +static int ct_send_nb(struct intel_guc_ct *ct,
>>> +		      const u32 *action,
>>> +		      u32 len,
>>> +		      u32 flags)
>>> +{
>>> +	struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
>>> +	unsigned long spin_flags;
>>> +	u32 fence;
>>> +	int ret;
>>> +
>>> +	spin_lock_irqsave(&ctb->lock, spin_flags);
>>> +
>>> +	ret = h2g_has_room(ctb, len + 1);
>>
>> but here you treat "1" it as en error
>>
> 
> Yes, this patch is broken but fixed in a follow up one. Regardless I'll
> fix this patch in place.
> 
>> and this "1" is GUC_HXG_MSG_MIN_LEN, right ?
>>
> 
> Not exactly. This is following how ct_send() uses the action + len
> field. Action[0] field goes in the HXG header and extra + 1 is for the
> CT header.

well, "len" already counts "action" so by treating input as full HXG
message (including HXG header) will make it cleaner

we can try do it later but by doing it right now we would avoid
introducing this send_nb() function and deprecating them long term again

> 
>>> +	if (unlikely(ret))
>>> +		goto out;
>>> +
>>> +	fence = ct_get_next_fence(ct);
>>> +	ret = ct_write(ct, action, len, fence, flags);
>>> +	if (unlikely(ret))
>>> +		goto out;
>>> +
>>> +	intel_guc_notify(ct_to_guc(ct));
>>> +
>>> +out:
>>> +	spin_unlock_irqrestore(&ctb->lock, spin_flags);
>>> +
>>> +	return ret;
>>> +}
>>> +
>>>  static int ct_send(struct intel_guc_ct *ct,
>>>  		   const u32 *action,
>>>  		   u32 len,
>>> @@ -505,6 +554,7 @@ static int ct_send(struct intel_guc_ct *ct,
>>>  		   u32 response_buf_size,
>>>  		   u32 *status)
>>>  {
>>> +	struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
>>>  	struct ct_request request;
>>>  	unsigned long flags;
>>>  	u32 fence;
>>> @@ -514,8 +564,20 @@ static int ct_send(struct intel_guc_ct *ct,
>>>  	GEM_BUG_ON(!len);
>>>  	GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
>>>  	GEM_BUG_ON(!response_buf && response_buf_size);
>>> +	might_sleep();
>>>  
>>> +	/*
>>> +	 * We use a lazy spin wait loop here as we believe that if the CT
>>> +	 * buffers are sized correctly the flow control condition should be
>>> +	 * rare.
>>
>> shouldn't we at least try to log such cases with RATE_LIMITED to find
>> out how "rare" it is, or if really unlikely just return -EBUSY as in
>> case of non-blocking send ?
>>
> 
> Definitely not return -EBUSY as this a blocking call. Perhaps we can log

blocking calls still can fail for various reasons, full CTB is one of
them, and if we return error (now broken) for non-blocking variant then
we should do the same for blocking variant as well and let the caller
decide about next steps

> this, but IGTs likely can hit rather easily. It really is only
> interesting if real workloads hit this. Regardless that can be a follow
> up.

if we hide retry in a silent loop then we will not find it out if we hit
this condition (IGT or real WL) or not

> 
> Matt
>  
>>> +	 */
>>> +retry:
>>>  	spin_lock_irqsave(&ct->ctbs.send.lock, flags);
>>> +	if (unlikely(!h2g_has_room(ctb, len + 1))) {
>>> +		spin_unlock_irqrestore(&ct->ctbs.send.lock, flags);
>>> +		cond_resched();
>>> +		goto retry;
>>> +	}
>>>  
>>>  	fence = ct_get_next_fence(ct);
>>>  	request.fence = fence;
>>> @@ -527,7 +589,7 @@ static int ct_send(struct intel_guc_ct *ct,
>>>  	list_add_tail(&request.link, &ct->requests.pending);
>>>  	spin_unlock(&ct->requests.lock);
>>>  
>>> -	err = ct_write(ct, action, len, fence);
>>> +	err = ct_write(ct, action, len, fence, 0);
>>>  
>>>  	spin_unlock_irqrestore(&ct->ctbs.send.lock, flags);
>>>  
>>> @@ -569,7 +631,7 @@ static int ct_send(struct intel_guc_ct *ct,
>>>   * Command Transport (CT) buffer based GuC send function.
>>>   */
>>>  int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
>>> -		      u32 *response_buf, u32 response_buf_size)
>>> +		      u32 *response_buf, u32 response_buf_size, u32 flags)
>>>  {
>>>  	u32 status = ~0; /* undefined */
>>>  	int ret;
>>> @@ -579,6 +641,9 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
>>>  		return -ENODEV;
>>>  	}
>>>  
>>> +	if (flags & INTEL_GUC_SEND_NB)
>>> +		return ct_send_nb(ct, action, len, flags);
>>> +
>>>  	ret = ct_send(ct, action, len, response_buf, response_buf_size, &status);
>>>  	if (unlikely(ret < 0)) {
>>>  		CT_ERROR(ct, "Sending action %#x failed (err=%d status=%#X)\n",
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
>>> index 1ae2dde6db93..eb69263324ba 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
>>> @@ -42,7 +42,6 @@ struct intel_guc_ct_buffer {
>>>  	bool broken;
>>>  };
>>>  
>>> -
>>>  /** Top-level structure for Command Transport related data
>>>   *
>>>   * Includes a pair of CT buffers for bi-directional communication and tracking
>>> @@ -88,7 +87,7 @@ static inline bool intel_guc_ct_enabled(struct intel_guc_ct *ct)
>>>  }
>>>  
>>>  int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
>>> -		      u32 *response_buf, u32 response_buf_size);
>>> +		      u32 *response_buf, u32 response_buf_size, u32 flags);
>>>  void intel_guc_ct_event_handler(struct intel_guc_ct *ct);
>>>  
>>>  #endif /* _INTEL_GUC_CT_H_ */
>>>


More information about the dri-devel mailing list