From: Simon Horman <horms@kernel.org>
To: Ahmed Zaki <ahmed.zaki@intel.com>
Cc: netdev@vger.kernel.org, anthony.l.nguyen@intel.com,
Marcin Szycik <marcin.szycik@linux.intel.com>,
intel-wired-lan@lists.osuosl.org,
Sridhar Samudrala <sridhar.samudrala@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v3 12/13] iavf: refactor add/del FDIR filters
Date: Wed, 24 Jul 2024 17:30:16 +0100 [thread overview]
Message-ID: <20240724163016.GB97837@kernel.org> (raw)
In-Reply-To: <4691e62b-0597-4184-8e85-0e74d8cdab85@intel.com>
On Wed, Jul 24, 2024 at 10:14:19AM -0600, Ahmed Zaki wrote:
...
> > > +/**
> > > + * iavf_fdir_del_fltr - delete a flow director filter from the list
> > > + * @adapter: pointer to the VF adapter structure
> > > + * @loc: location to delete.
> > > + *
> > > + * Return: 0 on success or negative errno on failure.
> > > + */
> > > +int iavf_fdir_del_fltr(struct iavf_adapter *adapter, u32 loc)
> > > +{
> > > + struct iavf_fdir_fltr *fltr = NULL;
> > > + int err = 0;
> > > +
> > > + spin_lock_bh(&adapter->fdir_fltr_lock);
> > > + fltr = iavf_find_fdir_fltr(adapter, loc);
> > > +
> > > + if (fltr) {
> > > + if (fltr->state == IAVF_FDIR_FLTR_ACTIVE) {
> > > + fltr->state = IAVF_FDIR_FLTR_DEL_REQUEST;
> > > + } else if (fltr->state == IAVF_FDIR_FLTR_INACTIVE) {
> > > + list_del(&fltr->list);
> > > + kfree(fltr);
> > > + adapter->fdir_active_fltr--;
> > > + fltr = NULL;
> > > + } else {
> > > + err = -EBUSY;
> > > + }
> > > + } else if (adapter->fdir_active_fltr) {
> > > + err = -EINVAL;
> > > + }
> > > +
> > > + if (fltr && fltr->state == IAVF_FDIR_FLTR_DEL_REQUEST)
> > > + iavf_schedule_aq_request(adapter, IAVF_FLAG_AQ_DEL_FDIR_FILTER);
> >
> > It seems that prior to this change the condition and call to
> > iavf_schedule_aq_request were not protected by fdir_fltr_lock, and now they
> > are. If so, is this change intentional.
> >
>
> yes it is, fltr is member of the list that should be protected by the
> spinlock.
Thanks,
I would suggest moving this into a separate patch: changing locking is a
bit different to refactoring.
Or, if not, at least mentioning it in the patch description.
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Ahmed Zaki <ahmed.zaki@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
anthony.l.nguyen@intel.com,
Sridhar Samudrala <sridhar.samudrala@intel.com>,
Marcin Szycik <marcin.szycik@linux.intel.com>
Subject: Re: [PATCH iwl-next v3 12/13] iavf: refactor add/del FDIR filters
Date: Wed, 24 Jul 2024 17:30:16 +0100 [thread overview]
Message-ID: <20240724163016.GB97837@kernel.org> (raw)
In-Reply-To: <4691e62b-0597-4184-8e85-0e74d8cdab85@intel.com>
On Wed, Jul 24, 2024 at 10:14:19AM -0600, Ahmed Zaki wrote:
...
> > > +/**
> > > + * iavf_fdir_del_fltr - delete a flow director filter from the list
> > > + * @adapter: pointer to the VF adapter structure
> > > + * @loc: location to delete.
> > > + *
> > > + * Return: 0 on success or negative errno on failure.
> > > + */
> > > +int iavf_fdir_del_fltr(struct iavf_adapter *adapter, u32 loc)
> > > +{
> > > + struct iavf_fdir_fltr *fltr = NULL;
> > > + int err = 0;
> > > +
> > > + spin_lock_bh(&adapter->fdir_fltr_lock);
> > > + fltr = iavf_find_fdir_fltr(adapter, loc);
> > > +
> > > + if (fltr) {
> > > + if (fltr->state == IAVF_FDIR_FLTR_ACTIVE) {
> > > + fltr->state = IAVF_FDIR_FLTR_DEL_REQUEST;
> > > + } else if (fltr->state == IAVF_FDIR_FLTR_INACTIVE) {
> > > + list_del(&fltr->list);
> > > + kfree(fltr);
> > > + adapter->fdir_active_fltr--;
> > > + fltr = NULL;
> > > + } else {
> > > + err = -EBUSY;
> > > + }
> > > + } else if (adapter->fdir_active_fltr) {
> > > + err = -EINVAL;
> > > + }
> > > +
> > > + if (fltr && fltr->state == IAVF_FDIR_FLTR_DEL_REQUEST)
> > > + iavf_schedule_aq_request(adapter, IAVF_FLAG_AQ_DEL_FDIR_FILTER);
> >
> > It seems that prior to this change the condition and call to
> > iavf_schedule_aq_request were not protected by fdir_fltr_lock, and now they
> > are. If so, is this change intentional.
> >
>
> yes it is, fltr is member of the list that should be protected by the
> spinlock.
Thanks,
I would suggest moving this into a separate patch: changing locking is a
bit different to refactoring.
Or, if not, at least mentioning it in the patch description.
next prev parent reply other threads:[~2024-07-24 16:30 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-10 20:40 [Intel-wired-lan] [PATCH iwl-next v3 00/13] ice: iavf: add support for TC U32 filters on VFs Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-10 20:40 ` [Intel-wired-lan] [PATCH iwl-next v3 01/13] ice: add parser create and destroy skeleton Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-22 15:05 ` [Intel-wired-lan] " Simon Horman
2024-07-22 15:05 ` Simon Horman
2024-07-10 20:40 ` [Intel-wired-lan] [PATCH iwl-next v3 02/13] ice: parse and init various DDP parser sections Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-11 5:28 ` [Intel-wired-lan] " Paul Menzel
2024-07-11 5:28 ` Paul Menzel
2024-07-15 14:16 ` Ahmed Zaki
2024-07-15 14:16 ` Ahmed Zaki
2024-07-22 14:52 ` Simon Horman
2024-07-22 14:52 ` Simon Horman
2024-07-10 20:40 ` [Intel-wired-lan] [PATCH iwl-next v3 03/13] ice: add debugging functions for the " Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-22 14:53 ` [Intel-wired-lan] " Simon Horman
2024-07-22 14:53 ` Simon Horman
2024-07-24 16:19 ` [Intel-wired-lan] " Ahmed Zaki
2024-07-24 16:19 ` Ahmed Zaki
2024-07-10 20:40 ` [Intel-wired-lan] [PATCH iwl-next v3 04/13] ice: add parser internal helper functions Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-22 15:06 ` [Intel-wired-lan] " Simon Horman
2024-07-22 15:06 ` Simon Horman
2024-07-10 20:40 ` [Intel-wired-lan] [PATCH iwl-next v3 05/13] ice: add parser execution main loop Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-22 15:01 ` [Intel-wired-lan] " Simon Horman
2024-07-22 15:01 ` Simon Horman
2024-07-10 20:40 ` [Intel-wired-lan] [PATCH iwl-next v3 06/13] ice: support turning on/off the parser's double vlan mode Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-22 15:02 ` [Intel-wired-lan] " Simon Horman
2024-07-22 15:02 ` Simon Horman
2024-07-10 20:40 ` [Intel-wired-lan] [PATCH iwl-next v3 07/13] ice: add UDP tunnels support to the parser Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-22 15:06 ` [Intel-wired-lan] " Simon Horman
2024-07-22 15:06 ` Simon Horman
2024-07-22 15:10 ` [Intel-wired-lan] " Simon Horman
2024-07-22 15:10 ` Simon Horman
2024-07-10 20:40 ` [Intel-wired-lan] [PATCH iwl-next v3 08/13] ice: add API for parser profile initialization Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-10 20:40 ` [Intel-wired-lan] [PATCH iwl-next v3 09/13] virtchnl: support raw packet in protocol header Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-22 15:10 ` [Intel-wired-lan] " Simon Horman
2024-07-22 15:10 ` Simon Horman
2024-07-10 20:40 ` [Intel-wired-lan] [PATCH iwl-next v3 10/13] ice: add method to disable FDIR SWAP option Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-11 4:59 ` [Intel-wired-lan] " Paul Menzel
2024-07-11 4:59 ` Paul Menzel
2024-07-15 14:23 ` Ahmed Zaki
2024-07-15 14:23 ` Ahmed Zaki
2024-07-17 9:55 ` Paul Menzel
2024-07-17 9:55 ` Paul Menzel
2024-07-18 16:54 ` Ahmed Zaki
2024-07-18 16:54 ` Ahmed Zaki
2024-07-10 20:40 ` [Intel-wired-lan] [PATCH iwl-next v3 11/13] ice: enable FDIR filters from raw binary patterns for VFs Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-11 5:42 ` [Intel-wired-lan] " Paul Menzel
2024-07-11 5:42 ` Paul Menzel
2024-07-15 14:33 ` Ahmed Zaki
2024-07-15 14:33 ` Ahmed Zaki
2024-07-22 15:03 ` Simon Horman
2024-07-22 15:03 ` Simon Horman
2024-07-10 20:40 ` [Intel-wired-lan] [PATCH iwl-next v3 12/13] iavf: refactor add/del FDIR filters Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-22 15:04 ` [Intel-wired-lan] " Simon Horman
2024-07-22 15:04 ` Simon Horman
2024-07-24 16:14 ` [Intel-wired-lan] " Ahmed Zaki
2024-07-24 16:14 ` Ahmed Zaki
2024-07-24 16:30 ` Simon Horman [this message]
2024-07-24 16:30 ` Simon Horman
2024-07-24 19:28 ` [Intel-wired-lan] " Ahmed Zaki
2024-07-24 19:28 ` Ahmed Zaki
2024-07-10 20:40 ` [Intel-wired-lan] [PATCH iwl-next v3 13/13] iavf: add support for offloading tc U32 cls filters Ahmed Zaki
2024-07-10 20:40 ` Ahmed Zaki
2024-07-22 15:05 ` [Intel-wired-lan] " Simon Horman
2024-07-22 15:05 ` 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=20240724163016.GB97837@kernel.org \
--to=horms@kernel.org \
--cc=ahmed.zaki@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=marcin.szycik@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=sridhar.samudrala@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 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.