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 16BFDA0C4C; Tue, 5 Oct 2021 18:25:18 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8A2B2413AF; Tue, 5 Oct 2021 18:25:17 +0200 (CEST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by mails.dpdk.org (Postfix) with ESMTP id 8E0E94139F for ; Tue, 5 Oct 2021 18:25:16 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id EAF57580FEF; Tue, 5 Oct 2021 12:25:15 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 05 Oct 2021 12:25:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= TM5scK5424g7m+RdN+OAy1bgwZi6ldWnwDtFQXhdkww=; b=FttbN8Amtc0GYLPY nMIh1yeOe+Q8O2cru4sw2JMY++xL+zyblsXrIkmvOzaql1JfGXAVKIfCos4OZ+3X F/RND5BUJoQ/n5erOZZ11evZpTsXpm/nY4mkcZQWC3k1pgCe/IBm4fDe6SIhwgvM JHvd+ZV/FRKXS0zeC+PMGiBQiDl/5aAMiPdZD6pqMlltmjIvIBIfh5C38joOa6ZP /DJznlGA9ZV46XWXZLp1wQ9LAZ1Bk3LSA1YB9D8ahv9nq/dy3aVSH2gcx6fw4h+D EdN5qz/LZnbCSjnZW17sjoprwYvKBxrUaRCfsZlKe03VXWiPnakDzSSeC825rit5 S76Lcg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=TM5scK5424g7m+RdN+OAy1bgwZi6ldWnwDtFQXhdk ww=; b=fj5qrqqZwCsdpPeQRabuy8vUEa9yteFT+88ntidLups7BFDhkuAPbUFPd gL783Gcfitn6D/J4iZ/VkJMPkLEEP+icieACe+T90AZSlXM1s8q5jWku8YWHz9aA fAKu7vEBYAgv4oJmn2NsR5faSZOoOEjEL+pZkKgqSpLhnzPxVkae220FO+MEPszU z6v7Xu3mUqxaKJX33DvyYiF1bDH5m2GZPSwSfx+WCZHV7T5dcJRy1CEPxxxNe0AT xOMo1aSoumdqTlDrwGUP+WCMts4iKrqaxtwByBaLkl4vdO0DNmKrjOwodyFZ/dBr llSiOMF2L9+0Bze8V94UdAIHtn/ag== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudelgedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 5 Oct 2021 12:25:05 -0400 (EDT) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: "dev@dpdk.org" , "Li, Xiaoyun" , "anoobj@marvell.com" , "jerinj@marvell.com" , "ndabilpuram@marvell.com" , "adwivedi@marvell.com" , "shepard.siegel@atomicrules.com" , "ed.czeck@atomicrules.com" , "john.miller@atomicrules.com" , "irusskikh@marvell.com" , "ajit.khaparde@broadcom.com" , "somnath.kotur@broadcom.com" , "rahul.lakkireddy@chelsio.com" , "hemant.agrawal@nxp.com" , "sachin.saxena@oss.nxp.com" , "Wang, Haiyue" , "Daley, John" , "hyonkim@cisco.com" , "Zhang, Qi Z" , "Wang, Xiao W" , "humin29@huawei.com" , "yisen.zhuang@huawei.com" , "oulijun@huawei.com" , "Xing, Beilei" , "Wu, Jingjing" , "Yang, Qiming" , "matan@nvidia.com" , "viacheslavo@nvidia.com" , "sthemmin@microsoft.com" , "longli@microsoft.com" , "heinrich.kuhn@corigine.com" , "kirankumark@marvell.com" , "andrew.rybchenko@oktetlabs.ru" , "mczekaj@marvell.com" , "jiawenwu@trustnetic.com" , "jianwang@trustnetic.com" , "maxime.coquelin@redhat.com" , "Xia, Chenbo" , "Yigit, Ferruh" , "mdr@ashroe.eu" , "Jayatheerthan, Jay" Date: Tue, 05 Oct 2021 18:25:02 +0200 Message-ID: <2511373.MtqfFSqeA6@thomas> In-Reply-To: References: <20211001140255.5726-1-konstantin.ananyev@intel.com> <3078390.3ff9TgJ5vr@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4 7/7] ethdev: hide eth dev related structures 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" 05/10/2021 18:19, Ananyev, Konstantin: > > 04/10/2021 15:56, Konstantin Ananyev: > > > Move rte_eth_dev, rte_eth_dev_data, rte_eth_rxtx_callback and related > > > data into private header (ethdev_driver.h). > > [...] > > > +/** > > > + * @internal > > > + * Structure used to hold information about the callbacks to be called for a > > > + * queue on RX and TX. > > > + */ > > > +struct rte_eth_rxtx_callback { > > > + struct rte_eth_rxtx_callback *next; > > > + union{ > > > + rte_rx_callback_fn rx; > > > + rte_tx_callback_fn tx; > > > + } fn; > > > + void *param; > > > +}; > > > + > > > +/** > > > + * @internal > > > + * The generic data structure associated with each ethernet device. > > > + * > > > + * Pointers to burst-oriented packet receive and transmit functions are > > > + * located at the beginning of the structure, along with the pointer to > > > + * where all the data elements for the particular device are stored in shared > > > + * memory. This split allows the function pointer and driver data to be per- > > > + * process, while the actual configuration data for the device is shared. > > > + */ > > > +struct rte_eth_dev { > > > + eth_rx_burst_t rx_pkt_burst; /**< Pointer to PMD receive function. */ > > > + eth_tx_burst_t tx_pkt_burst; /**< Pointer to PMD transmit function. */ > > > + eth_tx_prep_t tx_pkt_prepare; > > > + /**< Pointer to PMD transmit prepare function. */ > > > + eth_rx_queue_count_t rx_queue_count; > > > + /**< Get the number of used RX descriptors. */ > > > + eth_rx_descriptor_status_t rx_descriptor_status; > > > + /**< Check the status of a Rx descriptor. */ > > > + eth_tx_descriptor_status_t tx_descriptor_status; > > > + /**< Check the status of a Tx descriptor. */ > > > > Why not using the new struct rte_eth_fp_ops? > > We don't want to change each and every driver for this change. > The idea beyond it: > 1. PMDs keep to setup fast-path function pointers and related data > inside rte_eth_dev struct in the same way they did it before. > 2. Inside rte_eth_dev_start() and inside rte_eth_dev_probing_finish() > (for secondary process) we call eth_dev_fp_ops_setup, which > copies these function and data pointers into rte_eth_fp_ops[port_id]. > 3. Inside rte_eth_dev_stop() and inside rte_eth_dev_release_port() > we call eth_dev_fp_ops_reset(), which resets rte_eth_fp_ops[port_id] > into some dummy values. OK please add this explanation in the commit log. > > > + > > > + /** > > > + * Next two fields are per-device data but *data is shared between > > > + * primary and secondary processes and *process_private is per-process > > > + * private. The second one is managed by PMDs if necessary. > > > + */ > > > + struct rte_eth_dev_data *data; /**< Pointer to device data. */ > > > > We should mention that "data" is shared between processes. > > I think the comment above states exactly that. > In fact, it is just cut and paste from lib/ethdev/rte_ethdev_core.h to > lib/ethdev/ethdev_driver.h. True, but it is confusing, and we cannot have 2 comments for the same field. The sentence "Next two fields are per-device data" is useless. Let's comment each field separately. > > > + void *process_private; /**< Pointer to per-process device data. */ > > > + const struct eth_dev_ops *dev_ops; /**< Functions exported by PMD */ > > > + struct rte_device *device; /**< Backing device */ > > > + struct rte_intr_handle *intr_handle; /**< Device interrupt handle */ > > > + /** User application callbacks for NIC interrupts */ > > > + struct rte_eth_dev_cb_list link_intr_cbs; > > > + /** > > > + * User-supplied functions called from rx_burst to post-process > > > + * received packets before passing them to the user > > > + */ > > > + struct rte_eth_rxtx_callback *post_rx_burst_cbs[RTE_MAX_QUEUES_PER_PORT]; > > > + /** > > > + * User-supplied functions called from tx_burst to pre-process > > > + * received packets before passing them to the driver for transmission. > > > + */ > > > + struct rte_eth_rxtx_callback *pre_tx_burst_cbs[RTE_MAX_QUEUES_PER_PORT]; > > > + enum rte_eth_dev_state state; /**< Flag indicating the port state */ > > > + void *security_ctx; /**< Context for security ops */ > > > + > > > + uint64_t reserved_64s[4]; /**< Reserved for future fields */ > > > + void *reserved_ptrs[4]; /**< Reserved for future fields */ > > > +} __rte_cache_aligned; [...] > > > +extern struct rte_eth_dev rte_eth_devices[]; > > > > Later we should add a function to configure the size of this array dynamically > > in the early DPDK init stage. > > After we will hide rte_eth_devices[] and friends, we should be able to do > with them whatever we want. > But I suppose, that should be a subject of separate patch/discussion, > Probably not in 21.11 timeframe. Yes