[dpdk-dev] [PATCH] parray: introduce internal API for dynamic arrays
Ferruh Yigit
ferruh.yigit at intel.com
Fri Jun 18 12:47:13 CEST 2021
On 6/18/2021 10:14 AM, Morten Brørup wrote:
>> From: dev [mailto:dev-bounces at 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.
More information about the dev
mailing list