[dpdk-dev] [PATCH v2] net/af_packet: remove limitation on number of qpairs

Ferruh Yigit ferruh.yigit at intel.com
Mon Mar 2 17:17:04 CET 2020


On 2/28/2020 4:52 PM, John W. Linville wrote:
> On Fri, Feb 28, 2020 at 10:08:43AM +0000, Ferruh Yigit wrote:
>> On 2/27/2020 8:00 PM, Stephen Hemminger wrote:
>>> Since qpairs is part of the vdev arguments, there is no need to
>>> limit it to 16. The queue arrays can be dynamically sized based
>>> on the requested parameters.
>>>
>>> Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
>>> ---
>>>  drivers/net/af_packet/rte_eth_af_packet.c | 23 +++++++++++++++++------
>>>  1 file changed, 17 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/net/af_packet/rte_eth_af_packet.c b/drivers/net/af_packet/rte_eth_af_packet.c
>>> index f5806bf42c46..e5e0aa9277a8 100644
>>> --- a/drivers/net/af_packet/rte_eth_af_packet.c
>>> +++ b/drivers/net/af_packet/rte_eth_af_packet.c
>>> @@ -37,8 +37,6 @@
>>>  #define DFLT_FRAME_SIZE		(1 << 11)
>>>  #define DFLT_FRAME_COUNT	(1 << 9)
>>>  
>>> -#define RTE_PMD_AF_PACKET_MAX_RINGS 16
>>> -
>>>  struct pkt_rx_queue {
>>>  	int sockfd;
>>>  
>>> @@ -77,8 +75,8 @@ struct pmd_internals {
>>>  
>>>  	struct tpacket_req req;
>>>  
>>> -	struct pkt_rx_queue rx_queue[RTE_PMD_AF_PACKET_MAX_RINGS];
>>> -	struct pkt_tx_queue tx_queue[RTE_PMD_AF_PACKET_MAX_RINGS];
>>> +	struct pkt_rx_queue *rx_queue;
>>> +	struct pkt_tx_queue *tx_queue;
>>>  };
>>>  
>>>  static const char *valid_arguments[] = {
>>> @@ -601,6 +599,18 @@ rte_pmd_init_internals(struct rte_vdev_device *dev,
>>>  	if (*internals == NULL)
>>>  		return -1;
>>>  
>>> +
>>> +	(*internals)->rx_queue = rte_calloc_socket("af_packet_rx",
>>> +						nb_queues,
>>> +						sizeof(struct pkt_rx_queue),
>>> +						0, numa_node);
>>> +	(*internals)->tx_queue = rte_calloc_socket("af_packet_tx",
>>> +						nb_queues,
>>> +						sizeof(struct pkt_tx_queue),
>>> +						0, numa_node);
>>
>> Not for this patch but right now all queue initialization done during init based
>> on max queue PMD can support, we may move allocating and configuring queues in
>> 'eth_rx_queue_setup' & 'eth_tx_queue_setup' based on number of queue application
>> request, in the future...
>>
>>> +	if (!(*internals)->rx_queue || !(*internals)->tx_queue)
>>> +		return -1;
>>
>> If only one allocation fails, should we free the other?
> 
> Yeah, good catch.
> 

Will fix while merging.


More information about the dev mailing list