From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 259BDA0C46; Fri, 18 Jun 2021 12:47:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0D23A410DE; Fri, 18 Jun 2021 12:47:23 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id EB7F540150 for ; Fri, 18 Jun 2021 12:47:20 +0200 (CEST) IronPort-SDR: fMomojsCRdrRPEpzb7vCvHCVRf+q+0jRdDYAb5q8RB82nXGndqtWgJIJZlXCSXyVS8PgPICLO3 1LYgO6c+nhWw== X-IronPort-AV: E=McAfee;i="6200,9189,10018"; a="206573151" X-IronPort-AV: E=Sophos;i="5.83,283,1616482800"; d="scan'208";a="206573151" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2021 03:47:19 -0700 IronPort-SDR: b2H5IyA9akyDE3hptFiPZw1/60F1/IgkSo0GcFghdTjViUuect9lVir0zn0gNjveUlQfzcWTP4 /YSTgnjtNckA== X-IronPort-AV: E=Sophos;i="5.83,283,1616482800"; d="scan'208";a="422184143" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.219.119]) ([10.213.219.119]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2021 03:47:17 -0700 To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , "Ananyev, Konstantin" , Thomas Monjalon , "Richardson, Bruce" Cc: dev@dpdk.org, olivier.matz@6wind.com, andrew.rybchenko@oktetlabs.ru, honnappa.nagarahalli@arm.com, jerinj@marvell.com, gakhil@marvell.com References: <20210614105839.3379790-1-thomas@monjalon.net> <98CBD80474FA8B44BF855DF32C47DC35C6184E@smartserver.smartshare.dk> <2004320.XGyPsaEoyj@thomas> <98CBD80474FA8B44BF855DF32C47DC35C61868@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35C6186B@smartserver.smartshare.dk> From: Ferruh Yigit X-User: ferruhy Message-ID: <1189f7bc-10ab-7789-d059-d26ba7858501@intel.com> Date: Fri, 18 Jun 2021 11:47:13 +0100 MIME-Version: 1.0 In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C6186B@smartserver.smartshare.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] parray: introduce internal API for dynamic arrays X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.