[PATCH v2] net/idpf: refine Rx/Tx queue model info

Ferruh Yigit ferruh.yigit at amd.com
Thu Mar 2 11:06:37 CET 2023


On 3/2/2023 9:46 AM, Zhang, Qi Z wrote:
> 
> 
>> -----Original Message-----
>> From: Mingxia Liu <mingxia.liu at intel.com>
>> Sent: Thursday, March 2, 2023 3:27 AM
>> To: dev at dpdk.org
>> Cc: Wu, Jingjing <jingjing.wu at intel.com>; Xing, Beilei <beilei.xing at intel.com>;
>> Liu, Mingxia <mingxia.liu at intel.com>
>> Subject: [PATCH v2] net/idpf: refine Rx/Tx queue model info
>>
>> This patch updates queue mode info in struct idpf_adapter.
>> Using is_rx_singleq_model to diffentiate rx_singq and rx_splitq explicitly,
>> instead of deducing it from pointer values.
>>
>> Signed-off-by: Mingxia Liu <mingxia.liu at intel.com>
>> ---
>>  drivers/common/idpf/idpf_common_device.c | 4 ++--
>> drivers/common/idpf/idpf_common_device.h | 4 ++--
>>  drivers/common/idpf/idpf_common_rxtx.c   | 2 +-
>>  drivers/common/idpf/idpf_common_rxtx.h   | 5 +++++
>>  drivers/net/idpf/idpf_ethdev.c           | 4 ++--
>>  drivers/net/idpf/idpf_rxtx.c             | 6 +++---
>>  6 files changed, 15 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/common/idpf/idpf_common_device.c
>> b/drivers/common/idpf/idpf_common_device.c
>> index 5475a3e52c..c5e7bbf66c 100644
>> --- a/drivers/common/idpf/idpf_common_device.c
>> +++ b/drivers/common/idpf/idpf_common_device.c
>> @@ -623,7 +623,7 @@ idpf_vport_info_init(struct idpf_vport *vport,
>>  	struct idpf_adapter *adapter = vport->adapter;
>>
>>  	vport_info->vport_type =
>> rte_cpu_to_le_16(VIRTCHNL2_VPORT_TYPE_DEFAULT);
>> -	if (adapter->txq_model == 0) {
>> +	if (!adapter->is_tx_singleq) {
>>  		vport_info->txq_model =
>>  			rte_cpu_to_le_16(VIRTCHNL2_QUEUE_MODEL_SPLIT);
>>  		vport_info->num_tx_q =
>> @@ -636,7 +636,7 @@ idpf_vport_info_init(struct idpf_vport *vport,
>>  		vport_info->num_tx_q =
>> rte_cpu_to_le_16(IDPF_DEFAULT_TXQ_NUM);
>>  		vport_info->num_tx_complq = 0;
>>  	}
>> -	if (adapter->rxq_model == 0) {
>> +	if (!adapter->is_rx_singleq) {
>>  		vport_info->rxq_model =
>>  			rte_cpu_to_le_16(VIRTCHNL2_QUEUE_MODEL_SPLIT);
>>  		vport_info->num_rx_q =
>> rte_cpu_to_le_16(IDPF_DEFAULT_RXQ_NUM);
>> diff --git a/drivers/common/idpf/idpf_common_device.h
>> b/drivers/common/idpf/idpf_common_device.h
>> index 364a60221a..c2dc2f16b9 100644
>> --- a/drivers/common/idpf/idpf_common_device.h
>> +++ b/drivers/common/idpf/idpf_common_device.h
>> @@ -43,8 +43,8 @@ struct idpf_adapter {
>>
>>  	uint32_t ptype_tbl[IDPF_MAX_PKT_TYPE] __rte_cache_min_aligned;
>>
>> -	uint32_t txq_model; /* 0 - split queue model, non-0 - single queue
>> model */
>> -	uint32_t rxq_model; /* 0 - split queue model, non-0 - single queue
>> model */
>> +	bool is_tx_singleq; /* true - single queue model, false - split queue
>> model */
>> +	bool is_rx_singleq; /* true - single queue model, false - split queue
>> +model */
>>
>>  	/* For timestamp */
>>  	uint64_t time_hw;
>> diff --git a/drivers/common/idpf/idpf_common_rxtx.c
>> b/drivers/common/idpf/idpf_common_rxtx.c
>> index d7e8df1895..fc87e3e243 100644
>> --- a/drivers/common/idpf/idpf_common_rxtx.c
>> +++ b/drivers/common/idpf/idpf_common_rxtx.c
>> @@ -309,7 +309,7 @@ idpf_qc_rx_queue_release(void *rxq)
>>  		return;
>>
>>  	/* Split queue */
>> -	if (q->bufq1 != NULL && q->bufq2 != NULL) {
>> +	if (!q->adapter->is_rx_singleq) {
>>  		q->bufq1->ops->release_mbufs(q->bufq1);
>>  		rte_free(q->bufq1->sw_ring);
>>  		rte_memzone_free(q->bufq1->mz);
>> diff --git a/drivers/common/idpf/idpf_common_rxtx.h
>> b/drivers/common/idpf/idpf_common_rxtx.h
>> index 7e6df080e6..d0f79783b5 100644
>> --- a/drivers/common/idpf/idpf_common_rxtx.h
>> +++ b/drivers/common/idpf/idpf_common_rxtx.h
>> @@ -90,6 +90,11 @@
>>  #define PF_GLTSYN_SHTIME_L_5	(PF_TIMESYNC_BAR4_BASE + 0x138)
>>  #define PF_GLTSYN_SHTIME_H_5	(PF_TIMESYNC_BAR4_BASE + 0x13C)
>>
>> +enum idpf_rx_split_bufq_id {
>> +	IDPF_RX_SPLIT_BUFQ1_ID = 1,
>> +	IDPF_RX_SPLIT_BUFQ2_ID = 2
>> +};
> 
> enum type never be referenced, 
> it's not necessary, #define should be ok.
> 

Hi Qi,

Is it OK if I merge this patch directly to next-net (when it get your
ack), because of v8 CPFL dependency?
Otherwise it may cause issues in main if next-net pulled before
next-net-intel.


More information about the dev mailing list