Re: [dpdk-dev] [PATCH] parray: introduce internal API for dynamic arrays

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 6/18/2021 10:14 AM, Morten Brørup wrote:
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev,
>> Konstantin
>> Sent: Thursday, 17 June 2021 19.06
>>
>> I think it would be better to change rx_pkt_burst() to accept port_id
>> and queue_id, instead of void *.
> 
> Current:
> 
> typedef uint16_t (*eth_rx_burst_t)(void *rxq,
> 				   struct rte_mbuf **rx_pkts,
> 				   uint16_t nb_pkts);
> 
>> I.E:
>> typedef uint16_t (*eth_rx_burst_t)(uint16_t port_id,
>>     uint16_t queue_id,
>>     struct rte_mbuf **rx_pkts,
>>     uint16_t nb_pkts);
>>
>> And we can do actual de-referencing of private rxq data inside the
>> actual rx function.
> 
> Good idea, if it can be done without a performance cost.
> 
> The X64 calling convention allows up to 4 parameters passed as registers, so the added parameter should not be a problem.
> 
> 
> Another thing:
> 
> I just noticed that struct rte_eth_dev_data has "void **rx_queues;" (and similarly for tx_queues).
> 
> That should be "void *rx_queues[RTE_MAX_QUEUES_PER_PORT];", like in all the other ethdev structures.
> 

Why have a fixed size rx_queues array? It is already allocated dynamically in
'rte_eth_dev_configure()' based on actual Rx/Tx queue number.

We are already trying to get rid of compile time fixed array sizes, so I think
better to keep it as it is.

Also this will increase the strcut size.

> The same structure even has "uint8_t rx_queue_state[RTE_MAX_QUEUES_PER_PORT];", so it's following two different conventions.
> 

I wonder if we should should switch these to dynamic allocation too.