All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Karol Kolacinski <karol.kolacinski@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com,
	richardcochran@gmail.com, Milena Olech <milena.olech@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next 3/4] ice: use spin_lock for sideband queue send queue
Date: Fri, 6 Jun 2025 13:49:39 +0100	[thread overview]
Message-ID: <20250606124939.GA120308@horms.kernel.org> (raw)
In-Reply-To: <20250520110823.1937981-9-karol.kolacinski@intel.com>

On Tue, May 20, 2025 at 01:06:28PM +0200, Karol Kolacinski wrote:
> Sideband queue is a HW queue and has much faster completion time than
> other queues.
> 
> With <5 us for read on average it is possible to use spin_lock to be
> able to read/write sideband queue messages in the interrupt top half.
> 
> Add send queue lock/unlock operations and assign them based on the queue
> type. Use ice_sq_spin_lock/unlock for sideband queue and
> ice_sq_mutex_lock/unlock for other queues.
> 
> Reviewed-by: Milena Olech <milena.olech@intel.com>
> Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>

...

> +/**
> + * ice_sq_spin_lock - Call spin_lock_irqsave for union ice_sq_lock
> + * @lock: lock handle
> + */
> +static void ice_sq_spin_lock(union ice_sq_lock *lock)
> +	__acquires(&lock->sq_spinlock)
> +{
> +	spin_lock_irqsave(&lock->sq_spinlock, lock->sq_flags);
> +}
> +
> +/**
> + * ice_sq_spin_unlock - Call spin_unlock_irqrestore for union ice_sq_lock
> + * @lock: lock handle
> + */
> +static void ice_sq_spin_unlock(union ice_sq_lock *lock)
> +	__releases(&lock->sq_spinlock)
> +{
> +	spin_unlock_irqrestore(&lock->sq_spinlock, lock->sq_flags);
> +}
> +
> +/**
> + * ice_sq_mutex_lock - Call mutex_lock for union ice_sq_lock
> + * @lock: lock handle
> + */
> +static void ice_sq_mutex_lock(union ice_sq_lock *lock)
> +	__acquires(&lock->sq_mutex)
> +{
> +	mutex_lock(&lock->sq_mutex);
> +}
> +
> +/**
> + * ice_sq_mutex_unlock - Call mutex_unlock for union ice_sq_lock
> + * @lock: lock handle
> + */
> +static void ice_sq_mutex_unlock(union ice_sq_lock *lock)
> +	__releases(&lock->sq_mutex)
> +{
> +	mutex_unlock(&lock->sq_mutex);
> +}

Sparse seems unhappy about the annotations on the mutex functions above,
but curiously happy with those for the corresponding spinlock functions.
I am unsure why.

  .../ice_controlq.c:803:13: warning: context imbalance in 'ice_sq_mutex_lock' - wrong count at exit
  .../ice_controlq.c:813:13: warning: context imbalance in 'ice_sq_mutex_unlock' - wrong count at exit


> +
> +static struct ice_sq_ops ice_spin_ops = {
> +	.lock = ice_sq_spin_lock,
> +	.unlock = ice_sq_spin_unlock,
> +};
> +
> +static struct ice_sq_ops ice_mutex_ops = {
> +	.lock = ice_sq_mutex_lock,
> +	.unlock = ice_sq_mutex_unlock,
> +};
> +

...

WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Karol Kolacinski <karol.kolacinski@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com,
	richardcochran@gmail.com, Milena Olech <milena.olech@intel.com>
Subject: Re: [PATCH iwl-next 3/4] ice: use spin_lock for sideband queue send queue
Date: Fri, 6 Jun 2025 13:49:39 +0100	[thread overview]
Message-ID: <20250606124939.GA120308@horms.kernel.org> (raw)
In-Reply-To: <20250520110823.1937981-9-karol.kolacinski@intel.com>

On Tue, May 20, 2025 at 01:06:28PM +0200, Karol Kolacinski wrote:
> Sideband queue is a HW queue and has much faster completion time than
> other queues.
> 
> With <5 us for read on average it is possible to use spin_lock to be
> able to read/write sideband queue messages in the interrupt top half.
> 
> Add send queue lock/unlock operations and assign them based on the queue
> type. Use ice_sq_spin_lock/unlock for sideband queue and
> ice_sq_mutex_lock/unlock for other queues.
> 
> Reviewed-by: Milena Olech <milena.olech@intel.com>
> Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>

...

> +/**
> + * ice_sq_spin_lock - Call spin_lock_irqsave for union ice_sq_lock
> + * @lock: lock handle
> + */
> +static void ice_sq_spin_lock(union ice_sq_lock *lock)
> +	__acquires(&lock->sq_spinlock)
> +{
> +	spin_lock_irqsave(&lock->sq_spinlock, lock->sq_flags);
> +}
> +
> +/**
> + * ice_sq_spin_unlock - Call spin_unlock_irqrestore for union ice_sq_lock
> + * @lock: lock handle
> + */
> +static void ice_sq_spin_unlock(union ice_sq_lock *lock)
> +	__releases(&lock->sq_spinlock)
> +{
> +	spin_unlock_irqrestore(&lock->sq_spinlock, lock->sq_flags);
> +}
> +
> +/**
> + * ice_sq_mutex_lock - Call mutex_lock for union ice_sq_lock
> + * @lock: lock handle
> + */
> +static void ice_sq_mutex_lock(union ice_sq_lock *lock)
> +	__acquires(&lock->sq_mutex)
> +{
> +	mutex_lock(&lock->sq_mutex);
> +}
> +
> +/**
> + * ice_sq_mutex_unlock - Call mutex_unlock for union ice_sq_lock
> + * @lock: lock handle
> + */
> +static void ice_sq_mutex_unlock(union ice_sq_lock *lock)
> +	__releases(&lock->sq_mutex)
> +{
> +	mutex_unlock(&lock->sq_mutex);
> +}

Sparse seems unhappy about the annotations on the mutex functions above,
but curiously happy with those for the corresponding spinlock functions.
I am unsure why.

  .../ice_controlq.c:803:13: warning: context imbalance in 'ice_sq_mutex_lock' - wrong count at exit
  .../ice_controlq.c:813:13: warning: context imbalance in 'ice_sq_mutex_unlock' - wrong count at exit


> +
> +static struct ice_sq_ops ice_spin_ops = {
> +	.lock = ice_sq_spin_lock,
> +	.unlock = ice_sq_spin_unlock,
> +};
> +
> +static struct ice_sq_ops ice_mutex_ops = {
> +	.lock = ice_sq_mutex_lock,
> +	.unlock = ice_sq_mutex_unlock,
> +};
> +

...

  reply	other threads:[~2025-06-06 12:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-20 11:06 [Intel-wired-lan] [PATCH iwl-next 0/4] ice: Read Tx timestamps in the IRQ top half Karol Kolacinski
2025-05-20 11:06 ` Karol Kolacinski
2025-05-20 11:06 ` [Intel-wired-lan] [PATCH iwl-next 1/4] ice: skip completion for sideband queue writes Karol Kolacinski
2025-05-20 11:06   ` Karol Kolacinski
2025-05-22  6:47   ` [Intel-wired-lan] " Paul Menzel
2025-06-06 12:50   ` Simon Horman
2025-06-06 12:50     ` Simon Horman
2025-05-20 11:06 ` [Intel-wired-lan] [PATCH iwl-next 2/4] ice: refactor ice_sq_send_cmd and ice_shutdown_sq Karol Kolacinski
2025-05-20 11:06   ` Karol Kolacinski
2025-06-06 12:50   ` [Intel-wired-lan] " Simon Horman
2025-06-06 12:50     ` Simon Horman
2025-05-20 11:06 ` [Intel-wired-lan] [PATCH iwl-next 3/4] ice: use spin_lock for sideband queue send queue Karol Kolacinski
2025-05-20 11:06   ` Karol Kolacinski
2025-06-06 12:49   ` Simon Horman [this message]
2025-06-06 12:49     ` Simon Horman
2025-05-20 11:06 ` [Intel-wired-lan] [PATCH iwl-next 4/4] ice: read Tx timestamps in the IRQ top half Karol Kolacinski
2025-05-20 11:06   ` Karol Kolacinski
2025-06-06 12:50   ` [Intel-wired-lan] " Simon Horman
2025-06-06 12:50     ` Simon Horman

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=20250606124939.GA120308@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=anthony.l.nguyen@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=karol.kolacinski@intel.com \
    --cc=milena.olech@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=richardcochran@gmail.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.