All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH net] ice: Clear default forwarding VSI during VSI release
Date: Thu, 24 Mar 2022 12:10:51 +0100	[thread overview]
Message-ID: <YjxRu8hnNnuYCrcd@boxer> (raw)
In-Reply-To: <287f2247-2c58-497d-f7b1-ae1e24a88da8@linux.intel.com>

On Wed, Mar 23, 2022 at 07:19:55PM +0100, Marcin Szycik wrote:
> 
> 
> On 23-Mar-22 18:54, Ivan Vecera wrote:
> > On Wed, 23 Mar 2022 18:39:11 +0100
> > Marcin Szycik <marcin.szycik@linux.intel.com> wrote:
> > 
> >> On 22-Mar-22 15:25, Ivan Vecera wrote:
> >>> VSI is set as default forwarding one when promisc mode is set for
> >>> PF interface, when PF is switched to switchdev mode or when VF
> >>> driver asks to enable allmulticast or promisc mode for the VF
> >>> interface (when vf-true-promisc-support priv flag is off).
> >>> The third case is buggy because in that case VSI associated with
> >>> VF remains as default one after VF removal.
> >>>
> >>> Reproducer:
> >>> 1. Create VF
> >>>    echo 1 > sys/class/net/ens7f0/device/sriov_numvfs
> >>> 2. Enable allmulticast or promisc mode on VF
> >>>    ip link set ens7f0v0 allmulticast on
> >>>    ip link set ens7f0v0 promisc on
> >>> 3. Delete VF
> >>>    echo 0 > sys/class/net/ens7f0/device/sriov_numvfs
> >>> 4. Try to enable promisc mode on PF
> >>>    ip link set ens7f0 promisc on
> >>>
> >>> Although it looks that promisc mode on PF is enabled the opposite
> >>> is true because ice_vsi_sync_fltr() responsible for IFF_PROMISC
> >>> handling first checks if any other VSI is set as default forwarding
> >>> one and if so the function does not do anything. At this point
> >>> it is not possible to enable promisc mode on PF without re-probe
> >>> device.
> >>>
> >>> To resolve the issue this patch clear default forwarding VSI

tiny nit:
s/clear/clears

Also it's more welcome to use imperative mood.

> >>> during ice_vsi_release() when the VSI to be released is the default
> >>> one.
> >>>
> >>> Fixes: 01b5e89aab49 ("ice: Add VF promiscuous support")
> >>> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> >>> ---
> >>>  drivers/net/ethernet/intel/ice/ice_lib.c | 2 ++
> >>>  1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
> >>> index 53256aca27c7..20d755822d43 100644
> >>> --- a/drivers/net/ethernet/intel/ice/ice_lib.c
> >>> +++ b/drivers/net/ethernet/intel/ice/ice_lib.c
> >>> @@ -3147,6 +3147,8 @@ int ice_vsi_release(struct ice_vsi *vsi)
> >>>  		}
> >>>  	}
> >>>  
> >>> +	if (ice_is_vsi_dflt_vsi(pf->first_sw, vsi))
> >>> +		ice_clear_dflt_vsi(pf->first_sw);  
> >>
> >> It would probably be good to check `ice_clear_dflt_vsi` return code.
> > 
> > Check and report potential warning when error occurs? because we are in ice_vsi_release() so
> > any rollback does not make sense.

I believe that comment wouldn't hurt that it's ok to ignore the retval,
but then again i'm fine with what it is currently :)

Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>

> 
> Right. ice_clear_dflt_vsi already reports errors so it should be good as is.
> LGTM, thanks!
> 
> > 
> > Ivan
> > 

WARNING: multiple messages have this Message-ID (diff)
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Marcin Szycik <marcin.szycik@linux.intel.com>
Cc: Ivan Vecera <ivecera@redhat.com>,
	netdev@vger.kernel.org, poros@redhat.com, mschmidt@redhat.com,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Brett Creeley <brett.creeley@intel.com>,
	Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
	"moderated list:INTEL ETHERNET DRIVERS\"" 
	<intel-wired-lan@lists.osuosl.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net] ice: Clear default forwarding VSI during VSI release
Date: Thu, 24 Mar 2022 12:10:51 +0100	[thread overview]
Message-ID: <YjxRu8hnNnuYCrcd@boxer> (raw)
In-Reply-To: <287f2247-2c58-497d-f7b1-ae1e24a88da8@linux.intel.com>

On Wed, Mar 23, 2022 at 07:19:55PM +0100, Marcin Szycik wrote:
> 
> 
> On 23-Mar-22 18:54, Ivan Vecera wrote:
> > On Wed, 23 Mar 2022 18:39:11 +0100
> > Marcin Szycik <marcin.szycik@linux.intel.com> wrote:
> > 
> >> On 22-Mar-22 15:25, Ivan Vecera wrote:
> >>> VSI is set as default forwarding one when promisc mode is set for
> >>> PF interface, when PF is switched to switchdev mode or when VF
> >>> driver asks to enable allmulticast or promisc mode for the VF
> >>> interface (when vf-true-promisc-support priv flag is off).
> >>> The third case is buggy because in that case VSI associated with
> >>> VF remains as default one after VF removal.
> >>>
> >>> Reproducer:
> >>> 1. Create VF
> >>>    echo 1 > sys/class/net/ens7f0/device/sriov_numvfs
> >>> 2. Enable allmulticast or promisc mode on VF
> >>>    ip link set ens7f0v0 allmulticast on
> >>>    ip link set ens7f0v0 promisc on
> >>> 3. Delete VF
> >>>    echo 0 > sys/class/net/ens7f0/device/sriov_numvfs
> >>> 4. Try to enable promisc mode on PF
> >>>    ip link set ens7f0 promisc on
> >>>
> >>> Although it looks that promisc mode on PF is enabled the opposite
> >>> is true because ice_vsi_sync_fltr() responsible for IFF_PROMISC
> >>> handling first checks if any other VSI is set as default forwarding
> >>> one and if so the function does not do anything. At this point
> >>> it is not possible to enable promisc mode on PF without re-probe
> >>> device.
> >>>
> >>> To resolve the issue this patch clear default forwarding VSI

tiny nit:
s/clear/clears

Also it's more welcome to use imperative mood.

> >>> during ice_vsi_release() when the VSI to be released is the default
> >>> one.
> >>>
> >>> Fixes: 01b5e89aab49 ("ice: Add VF promiscuous support")
> >>> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> >>> ---
> >>>  drivers/net/ethernet/intel/ice/ice_lib.c | 2 ++
> >>>  1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
> >>> index 53256aca27c7..20d755822d43 100644
> >>> --- a/drivers/net/ethernet/intel/ice/ice_lib.c
> >>> +++ b/drivers/net/ethernet/intel/ice/ice_lib.c
> >>> @@ -3147,6 +3147,8 @@ int ice_vsi_release(struct ice_vsi *vsi)
> >>>  		}
> >>>  	}
> >>>  
> >>> +	if (ice_is_vsi_dflt_vsi(pf->first_sw, vsi))
> >>> +		ice_clear_dflt_vsi(pf->first_sw);  
> >>
> >> It would probably be good to check `ice_clear_dflt_vsi` return code.
> > 
> > Check and report potential warning when error occurs? because we are in ice_vsi_release() so
> > any rollback does not make sense.

I believe that comment wouldn't hurt that it's ok to ignore the retval,
but then again i'm fine with what it is currently :)

Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>

> 
> Right. ice_clear_dflt_vsi already reports errors so it should be good as is.
> LGTM, thanks!
> 
> > 
> > Ivan
> > 

  reply	other threads:[~2022-03-24 11:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-22 14:25 [Intel-wired-lan] [PATCH net] ice: Clear default forwarding VSI during VSI release Ivan Vecera
2022-03-22 14:25 ` Ivan Vecera
2022-03-23 17:39 ` [Intel-wired-lan] " Marcin Szycik
2022-03-23 17:39   ` Marcin Szycik
2022-03-23 17:54   ` [Intel-wired-lan] " Ivan Vecera
2022-03-23 18:19     ` Marcin Szycik
2022-03-23 18:19       ` Marcin Szycik
2022-03-24 11:10       ` Maciej Fijalkowski [this message]
2022-03-24 11:10         ` Maciej Fijalkowski
2022-03-24  7:09 ` [Intel-wired-lan] " Michal Swiatkowski
2022-03-24  7:09   ` Michal Swiatkowski

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=YjxRu8hnNnuYCrcd@boxer \
    --to=maciej.fijalkowski@intel.com \
    --cc=intel-wired-lan@osuosl.org \
    /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.