Re: [PATCH iwl-next v1 12/15] ice: introduce handling of virtchnl LARGE VF opcodes

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

On 5/8/26 18:55, Loktionov, Aleksandr wrote:
> 
> 
>> -----Original Message-----
>> From: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>
>> Sent: Friday, May 8, 2026 2:42 PM
>> To: intel-wired-lan@lists.osuosl.org; Schmidt, Michal
>> <mschmidt@redhat.com>; Jakub Kicinski <kuba@kernel.org>; Jiri Pirko
>> <jiri@resnulli.us>
>> Cc: netdev@vger.kernel.org; Simon Horman <horms@kernel.org>; Nguyen,
>> Anthony L <anthony.l.nguyen@intel.com>; Michal Swiatkowski
>> <michal.swiatkowski@linux.intel.com>; Richardson, Bruce
>> <bruce.richardson@intel.com>; Medvedkin, Vladimir
>> <vladimir.medvedkin@intel.com>; Connolly, Padraig J
>> <padraig.j.connolly@intel.com>; S, Ananth <ananth.s@intel.com>;
>> Miskell, Timothy <timothy.miskell@intel.com>; Keller, Jacob E
>> <jacob.e.keller@intel.com>; Czapnik, Lukasz
>> <lukasz.czapnik@intel.com>; Loktionov, Aleksandr
>> <aleksandr.loktionov@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>;
>> David S. Miller <davem@davemloft.net>; Eric Dumazet
>> <edumazet@google.com>; Paolo Abeni <pabeni@redhat.com>; Saeed Mahameed
>> <saeedm@nvidia.com>; Leon Romanovsky <leon@kernel.org>; Tariq Toukan
>> <tariqt@nvidia.com>; Mark Bloch <mbloch@nvidia.com>; Kitszel,
>> Przemyslaw <przemyslaw.kitszel@intel.com>
>> Subject: [PATCH iwl-next v1 12/15] ice: introduce handling of virtchnl
>> LARGE VF opcodes
>>
>> From: Brett Creeley <brett.creeley@intel.com>
>>
>> With new virtchnl offload/capability VFs are able to make use of more
>> than
>> 16 queues. But to old opcodes were designed with a max of 16 queues,
>> so new ones were added (by iavf/virtchnl commit of this series):
>> VIRTCHNL_OP_GET_MAX_RSS_QREGION, VIRTCHNL_OP_ENABLE_QUEUES_V2,
>> VIRTCHNL_OP_DISABLE_QUEUES_V2, VIRTCHNL_OP_MAP_QUEUE_VECTOR.
>>
>> If a VF wishes to request >16 queues it should first make sure that
>> the PF supports the VIRTCHNL_VF_LARGE_NUM_QPAIRS capability.
>>
>> Co-developed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
>> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
>> Co-developed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> #
>> msglen val
>> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>> Signed-off-by: Brett Creeley <brett.creeley@intel.com>
>> ---
>>   drivers/net/ethernet/intel/ice/ice_vf_lib.h   |   1 +
>>   drivers/net/ethernet/intel/ice/virt/queues.h  |   3 +
>>   .../net/ethernet/intel/ice/virt/allowlist.c   |   8 +
>>   drivers/net/ethernet/intel/ice/virt/queues.c  | 324
>> ++++++++++++++++++
>>   4 files changed, 336 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.h
>> b/drivers/net/ethernet/intel/ice/ice_vf_lib.h
>> index 1b56f7150eb7..5411eaa1761c 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_vf_lib.h
>> +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.h
>> @@ -125,6 +125,7 @@ struct ice_vf_ops {
>>   	void (*clear_reset_trigger)(struct ice_vf *vf);
>>   	void (*irq_close)(struct ice_vf *vf);
>>   	void (*post_vsi_rebuild)(struct ice_vf *vf);
> 
> ...
> 
>> +/**
>> + * ice_vc_map_q_vector_msg - message handling for
>> +VIRTCHNL_OP_MAP_QUEUE_VECTOR
>> + * @vf: source of the request
>> + * @msg: message to handle
>> + * @msglen: length of @msg
>> + *
>> + * Return: 0 on success or negative on error  */ int
>> +ice_vc_map_q_vector_msg(struct ice_vf *vf, u8 *msg, u16 msglen) {
>> +	enum virtchnl_status_code v_ret = VIRTCHNL_STATUS_SUCCESS;
>> +	struct virtchnl_queue_vector_maps *qv_maps;
>> +	struct ice_vsi *vsi;
>> +
>> +	qv_maps = (struct virtchnl_queue_vector_maps *)msg;
>> +
>> +	if (!ice_vc_validate_qv_maps(vf, qv_maps, msglen)) {
>> +		v_ret = VIRTCHNL_STATUS_ERR_PARAM;
>> +		goto error_param;
>> +	}
>> +
>> +	for (int i = 0; i < qv_maps->num_qv_maps; i++) {
>> +		struct virtchnl_queue_vector *qv_map = &qv_maps-
>>> qv_maps[i];
>> +		struct ice_q_vector *q_vector;
>> +		u16 vector_id;
>> +		int vsi_q_id;
>> +
>> +		vsi = ice_get_vf_vsi(vf);
>> +		vsi_q_id = qv_map->queue_id;
>> +		vector_id = qv_map->vector_id;
>> +
>> +		if (!vsi) {
>> +			v_ret = VIRTCHNL_STATUS_ERR_PARAM;
>> +			goto error_param;
>> +		}
>> +
>> +		q_vector = vf->vf_ops->get_q_vector(vsi, vector_id);
>> +
>> +		if (!q_vector) {
>> +			v_ret = VIRTCHNL_STATUS_ERR_PARAM;
>> +			goto error_param;
>> +		}
>> +
>> +		if (!ice_vc_isvalid_q_id(vsi, vsi_q_id))
> This function declared as returning linux errno, not enum.
> And in this case there is no reply to VF (goto error_param), couldn't it lead to VF stall?

good catch, will fix it
it wouldn't be VF stall, but an ugly "PF not replied to our request" msg

> 
>> +			return VIRTCHNL_STATUS_ERR_PARAM;
>> +
>> +		if (qv_map->queue_type == VIRTCHNL_QUEUE_TYPE_RX)
>> +			ice_cfg_rxq_interrupt(vsi, vsi_q_id,
>> +					      q_vector->vf_reg_idx,
>> +					      qv_map->itr_idx);
>> +		else if (qv_map->queue_type == VIRTCHNL_QUEUE_TYPE_TX)
>> +			ice_cfg_txq_interrupt(vsi, vsi_q_id,
>> +					      q_vector->vf_reg_idx,
>> +					      qv_map->itr_idx);
>> +	}
>> +
>> +error_param:
>> +	return ice_vc_send_msg_to_vf(vf, VIRTCHNL_OP_MAP_QUEUE_VECTOR,
>> +				     v_ret, NULL, 0);
>> +}
>> --
>> 2.39.3
>