Re: [Intel-wired-lan] [PATCH iwl-next v4] ice: replace ice_vf_recreate_vsi() with ice_vf_reconfig_vsi()

[Przemek Kitszel <przemyslaw.kitszel@intel.com>]

On 11/28/23 20:42, Jacob Keller wrote:
> The ice_vf_create_vsi() function and its VF ops helper introduced by commit
> a4c785e8162e ("ice: convert vf_ops .vsi_rebuild to .create_vsi") are used
> during an individual VF reset to re-create the VSI. This was done in order
> to ensure that the VSI gets properly reconfigured within the hardware.
> 
> This is somewhat heavy handed as we completely release the VSI memory and
> structure, and then create a new VSI. This can also potentially force a
> change of the VSI index as we will re-use the first open slot in the VSI
> array which may not be the same.
> 
> As part of implementing devlink reload, commit 6624e780a577 ("ice: split
> ice_vsi_setup into smaller functions") split VSI setup into smaller
> functions, introducing both ice_vsi_cfg() and ice_vsi_decfg() which can be
> used to configure or deconfigure an existing software VSI structure.
> 
> Rather than completely removing the VSI and adding a new one using the
> .create_vsi() VF operation, simply use ice_vsi_decfg() to remove the
> current configuration. Save the VSI type and then call ice_vsi_cfg() to
> reconfigure the VSI as the same type that it was before.
> 
> The existing reset logic assumes that all hardware filters will be removed,
> so also call ice_fltr_remove_all() before re-configuring the VSI.

[here]

> 
> This new operation does not re-create the VSI, so rename it to
> ice_vf_reconfig_vsi().
> 
> The new approach can safely share the exact same flow for both SR-IOV VFs
> as well as the Scalable IOV VFs being worked on. This uses less code and is
> a better abstraction over fully deleting the VSI and adding a new one.
> 
> Fixes: a4c785e8162e ("ice: convert vf_ops .vsi_rebuild to .create_vsi")

I see no such SHA in my tree.
Anyway, perhaps this patch could be targeted to -net?

> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> ---
> Changes since v3:
> * Removal of filters was a side effect of VSI being fully deleted by
>    firmware. Since we don't do that now, it was not happening. Fix this by
>    adding a call to ice_fltr_remove_all(). Thanks to Jakub Buchocki for

I could imagine giving credits also in the commit msg [here] :)

>    figuring out this solution.
> * Rebase on to current dev-queue.
> 
> v3 was posted at https://lore.kernel.org/intel-wired-lan/20230712222936.1048751-1-jacob.e.keller@intel.com/
> v2 was posted at https://lore.kernel.org/intel-wired-lan/20230712204730.326331-1-jacob.e.keller@intel.com/
> v1 was posted at https://lore.kernel.org/intel-wired-lan/20230504211829.3869868-1-jacob.e.keller@intel.com/
> 
> 
>   drivers/net/ethernet/intel/ice/ice_sriov.c    | 24 ++-----------
>   drivers/net/ethernet/intel/ice/ice_vf_lib.c   | 35 +++++++++++++------
>   drivers/net/ethernet/intel/ice/ice_vf_lib.h   |  1 -
>   .../ethernet/intel/ice/ice_vf_lib_private.h   |  1 +
>   4 files changed, 28 insertions(+), 33 deletions(-)
> 

code is fine, so:
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>


> base-commit: 0392e4d0c1cd583c079a18685cd308f8ce903793

that's good reason to ask for a re-test after long time, I agree!

My tree also does not have this SHA, you could likely base it on current 
"netdev/main"
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan