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 33C9843AC4; Fri, 9 Feb 2024 12:18:32 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F131540697; Fri, 9 Feb 2024 12:18:31 +0100 (CET) Received: from fout7-smtp.messagingengine.com (fout7-smtp.messagingengine.com [103.168.172.150]) by mails.dpdk.org (Postfix) with ESMTP id 9F1164026A for ; Fri, 9 Feb 2024 12:18:29 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id E905B1380079; Fri, 9 Feb 2024 06:18:28 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 09 Feb 2024 06:18:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1707477508; x=1707563908; bh=yN19H1HZHs0ko7bIAOm4QXNkVPB7FxnUIaSfARVOel0=; b= PZD4RlTG66Ix4HRzvIbX8fx8MyOlZ8DZ5oHzqssE9x/UYaouyGQZqRP4p+jhTiEl cpmqU2pUaNF9IQaQXGQ2IkrB2GCjvwLr579R7QB/AygdMmYQIK7spipk9XsRPx+M 4oBb6PSDEQl0EUUrO1dqC6WEn6Wp3NFwrx64ljQUQL3N+hVvnGsuFYSFdX3YqTb4 Al12Oqv3NnIOmojNYsxrWORj+fjznG1fzDvZod0ifgvD7pDmDm2SHr28ssIngYlS b0PP+tGaHHKehKCGNqd1kVYREaCVZ5kv4MPlsXoQhu4uPEYJoNCeid+I0TSt6yKn R6OvSC735yET0yiy9j3P9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1707477508; x= 1707563908; bh=yN19H1HZHs0ko7bIAOm4QXNkVPB7FxnUIaSfARVOel0=; b=B RhIj+40E1DG6MqZxPVJcyqA3QeSElTObkKucCeDqfKVur3GRUM8c1u8H9o8H9eQi vhWQHOTHS5kkmZo/dMQ0Wap52WJYAdgNTeeiNygBM36S25jM9fko9AnsH0rKWYNP kghim815FOS+qI5fzP6A3a5x2KOa7LzMBa0/XcP2hQGI/5QHZ2OOnGN+F4EXgWxr zpWwzQhBS+60ZObLcRbe8HBj2iAZqclvPGoW+ez2UhbCxe0RoDyEdeXKnQskQnZE d/2bRlHiiuz1AfBrVDrbWtLtDQ3Xh2zCn5aAOTFhh/Kuf9b1yxTCOTknaObA1PS0 4/aSe2OTzOcptCN4zT1sQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrtdeigddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 9 Feb 2024 06:18:27 -0500 (EST) From: Thomas Monjalon To: fengchengwen , Amit Prakash Shukla Cc: Kevin Laatz , Bruce Richardson , "dev@dpdk.org" , Jerin Jacob , Vamsi Krishna Attunuru , Nithin Kumar Dabilpuram , Anoob Joseph , "mb@smartsharesystems.com" Subject: Re: [EXT] Re: [PATCH v2] lib/dmadev: get DMA device using device ID Date: Fri, 09 Feb 2024 12:18:25 +0100 Message-ID: <2153070.3Lj2Plt8kZ@thomas> In-Reply-To: References: <20231208075526.2696553-1-amitprakashs@marvell.com> <069660f9-2940-23de-4b6a-beaea1acf944@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 09/02/2024 12:05, Amit Prakash Shukla: > > On 2024/2/9 0:25, Thomas Monjalon wrote: > > > 19/12/2023 12:00, Amit Prakash Shukla: > > >> +struct rte_dma_dev * > > >> +rte_dma_pmd_get_dev_by_id(const int dev_id) > > > const does not make sense here for an int parameter. > > > > > > I think it could be OK with const even if the parameter is not pointer. > > > > However, most DPDK APIs do not have const for simple types (e.g. > > int/uin16_t). > > > > In this aspect, I think it's also OK to remove const of here for consistency. > > > > > > > > > >> +{ > > >> + if (!rte_dma_is_valid(dev_id)) > > >> + return NULL; > > >> + > > >> + return &rte_dma_devices[dev_id]; > > >> +} > > > [...] > > >> +/** > > >> + * @internal > > >> + * Get the rte_dma_dev structure device pointer for the device id. > > >> + * > > >> + * @param dev_id > > >> + * Device ID value to select the device structure. > > > This comment is not explanatory. > > > What is an ID? Where does it come from? > > > Where can we see such ID for DMA device? > > > > This new API is used in the event-dma driver of cnxk [1]: > > > > The rte_event_dma_adapter_vchan_add has parameter of dma_dev_id, and it > > then > > > > invoke (*dev->dev_ops->dma_adapter_vchan_add)(dev, dma_dev_id, vchan, > > event), > > > > at cnxk driver, this ops will check whether the DMA is > > cnxk_dmadev_pci_driver. > > > > I think this is because the cnxk's event-and-dma implement has deep coupling > > > > (because the cnxk's event device could interact with another vendor's > > dma device). > > > > > > Maybe we should think of a better way to solve this kind of coupling > > problem. > > Id, is the DMA dev id which is used in looking up DMA dev. This API is in-line with the other libraries. > Crypto library has an api rte_cryptodev_pmd_get_dev to get crypto device based on device id. OK I think I understand. It is the library ID, the same as returned by int rte_dma_get_dev_id_by_name(const char *name); I can remove the const and apply if you are OK. I would just change this comment: + * @param dev_id + * Device ID value to select the device structure. into + * DMA device index in dmadev library.