From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3FB8CC433F5 for ; Thu, 9 Sep 2021 15:12:41 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 73EC761131 for ; Thu, 9 Sep 2021 15:12:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 73EC761131 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=smartsharesystems.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8824D40041; Thu, 9 Sep 2021 17:12:39 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 40DD64003E for ; Thu, 9 Sep 2021 17:12:39 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Sep 2021 17:12:35 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C61A62@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dpdk-dev] [PATCH v21 1/7] dmadev: introduce DMA device library public APIs Thread-Index: AdelhwRgVN41tRXRTmWkZOY/puCYkgAAXvXw References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <1855788.BnNMhiXu0z@thomas> <1912226.bRRTmGCQLz@thomas> <4108b879-a365-67db-72bb-1deb8440fa73@huawei.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" , "fengchengwen" Cc: "Thomas Monjalon" , , , , , , , , , , , , , , , Subject: Re: [dpdk-dev] [PATCH v21 1/7] dmadev: introduce DMA device library public APIs 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" > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > Sent: Thursday, 9 September 2021 16.29 >=20 > On Thu, Sep 09, 2021 at 09:54:27PM +0800, fengchengwen wrote: > > On 2021/9/9 20:45, Bruce Richardson wrote: > > > On Thu, Sep 09, 2021 at 01:29:33PM +0200, Thomas Monjalon wrote: > > >> 09/09/2021 13:18, Bruce Richardson: > > >>> On Thu, Sep 09, 2021 at 12:33:00PM +0200, Thomas Monjalon wrote: > > >>>> 07/09/2021 14:56, Chengwen Feng: [snip] > > >>>>> +bool > > >>>>> +rte_dmadev_is_valid_dev(uint16_t dev_id); > > >>>> > > >>>> I would suggest dropping the final "_dev" in the function name. > > >>>> > > >>> > > >>> The alternative, which I would support, is replacing = "rte_dmadev" > with > > >>> "rte_dma" across the API. This would then become > "rte_dma_is_valid_dev" > > >>> which is clearer, since the dev is not part of the standard > prefix. It also > > >>> would fit in with a possible future function of > "rte_dma_is_valid_vchan" > > >>> for instance. > > >> > > >> Yes > > >> The question is whether it would make sense to reserver rte_dma_ > prefix > > >> for some DMA functions which would be outside of dmadev lib? > > >> If you think that all DMA functions will be in dmadev, > > >> then yes we can shorten the prefix to rte_dma_. > > >> > > > > > > Well, any DPDK dma functions which are not in dma library should > have the > > > prefix of the library they are in e.g. rte_eal_dma_*, = rte_pci_dma_* > > > Therefore, I don't think name conflicts should be an issue, and I > like > > > having less typing to do in function names (and I believe Morten > was > > > strongly proposing this previously too) > > > > The dmadev is rather short, if change I prefer all public API with > rte_dma_ prefix, > > and don't have rte_dma_dev_ prefix for such start/stop/close. (ps: > the rte_eth_ also > > have rte_eth_dev_close which is painful for OCD). >=20 > I agree that having rte_dma_dev_* is unpleasant naming for those > functions, > so if we use rte_dma_ as prefix, any dev should be at the end instead: > i.e. rte_dma_stop_dev, rte_dma_start_dev, rte_dma_close_dev, etc. >=20 I agree about using rte_dma_ as general prefix. But I disagree about rte_dma__() function names, such as = rte_dma_stop_dev(). We should follow the convention of rte_dma__(), like in = the ethdev library, e.g. rte_eth_dev_get(), = rte_eth_fec_get_capability(). Or simply rte_dma_(), if the object is obvious and can be = omitted. I.e. rte_dma_dev_stop() or rte_dma_stop(). > > > > Also should the filename(e.g. rte_dmadev.h) and directory- > name(lib/dmadev) also change ? > > > I would keep those names intact. Keep intact, as Bruce suggests. This also aligns with the ethdev = library. >=20 > /Bruce