Re: [Intel-wired-lan] [PATCH iwl-next 08/14] idpf: refactor idpf to use libeth controlq and Xn APIs

[Simon Horman <horms@kernel.org>]

On Tue, Apr 08, 2025 at 02:47:54PM +0200, Larysa Zaremba wrote:
> From: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> 
> Support to initialize and configure controlq, Xn manager,
> MMIO and reset APIs was introduced in libeth. As part of it,
> most of the existing controlq structures are renamed and
> modified. Use those APIs in idpf and make all the necessary changes.
> 
> Previously for the send and receive virtchnl messages, there
> used to be a memcpy involved in controlq code to copy the buffer
> info passed by the send function into the controlq specific
> buffers. There was no restriction to use automatic memory
> in that case. The new implementation in libeth removed copying
> of the send buffer info and introduced DMA mapping of the
> send buffer itself. To accommodate it, use dynamic memory for
> the send buffers. In case of receive, idpf receives a page pool
> buffer allocated by the libeth and care should be taken to
> release it after use in the idpf.
> 
> The changes are fairly trivial and localized, with a notable exception
> being the consolidation of idpf_vc_xn_shutdown and idpf_deinit_dflt_mbx
> under the latter name. This has some additional consequences that are
> addressed in the following patches.
> 
> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>

...

> diff --git a/drivers/net/ethernet/intel/idpf/idpf.h b/drivers/net/ethernet/intel/idpf/idpf.h

...

> @@ -488,7 +486,10 @@ struct idpf_vc_xn_manager;
>   * @state: Init state machine
>   * @flags: See enum idpf_flags
>   * @reset_reg: See struct idpf_reset_reg
> - * @hw: Device access data
> + * @ctlq_ctx: controlq context
> + * @asq: Send control queue info
> + * @arq: Receive control queue info
> + * @xn_init_params: Xn transaction manager parameters
>   * @num_req_msix: Requested number of MSIX vectors
>   * @num_avail_msix: Available number of MSIX vectors
>   * @num_msix_entries: Number of entries in MSIX table
> @@ -540,7 +541,10 @@ struct idpf_adapter {
>  	enum idpf_state state;
>  	DECLARE_BITMAP(flags, IDPF_FLAGS_NBITS);
>  	struct idpf_reset_reg reset_reg;
> -	struct idpf_hw hw;
> +	struct libeth_ctlq_ctx ctlq_ctx;
> +	struct libeth_ctlq_info *asq;
> +	struct libeth_ctlq_info *arq;
> +	struct libeth_ctlq_xn_init_params xn_init_params;
>  	u16 num_req_msix;
>  	u16 num_avail_msix;
>  	u16 num_msix_entries;
> @@ -573,7 +577,6 @@ struct idpf_adapter {
>  	struct delayed_work stats_task;
>  	struct workqueue_struct *stats_wq;
>  	struct virtchnl2_get_capabilities caps;
> -	struct idpf_vc_xn_manager *vcxn_mngr;

nit: Please also drop the vcxn_mngr from the Kernel doc for struct idpf_adapter.

>  
>  	struct idpf_dev_ops dev_ops;
>  	int num_vfs;