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 E5D66A0C41; Thu, 15 Jul 2021 14:32:24 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 68C444014D; Thu, 15 Jul 2021 14:32:24 +0200 (CEST) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by mails.dpdk.org (Postfix) with ESMTP id 6533B40143 for ; Thu, 15 Jul 2021 14:32:23 +0200 (CEST) Received: by mail-io1-f50.google.com with SMTP id u7so6207456ion.3 for ; Thu, 15 Jul 2021 05:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1rZ5HseXOUgr/L31SMgo051CPnCv/i6nC0snWb6qZas=; b=jdKsQd0D22X13Okfwl3jrpVgTc2s3ihAo00uCRt3cEuzyaCg6fJmKi24ej/6mGeaOg 0ndEoGZsZmNVIcP1aB+KYMqPbThIoALGgUMcBVSCiMH7felLbdeZlbQeP3aMZQVumnsn 9chxjxSgi9HbxDIK1KyoF1v/IEOzoRxZmj/zFVZyzYfh+doU1iTNzjAUeiIDE1UhRxWz NjgWf/bVj1uCkO7wEko28KaJQkWHwUtItwFzUS8a/wa2m7m5DUQnjF6Skie2ONWF04Uk teEkYJwFlFUyg2dg3YRiTCh7F02SOQpP8DzlH+jAORYHNuV9HnKKAS0qfCfnGeIDg/rN 4qvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1rZ5HseXOUgr/L31SMgo051CPnCv/i6nC0snWb6qZas=; b=VLozMzQReTYOaLMpb282tLdU9Jt1bgTTgfy7jARqbstNqZFnfVittuPh0ieHTDbJ6N gysKcjiLtdkQKWSXvjpqQ3mNTj7QnGdD2Qu0VrbHDpngfCg50flBtcS57sP3xxSU+84l 264p0Tfq6DsnmC9EvsRADupUfwbH8Bt2C6ZG6HySnzo9TPkNY2eiX438luQbrT36UYTM Bho7ubmM+HHlW5TiKocZzPgH2oLYlN6NUaNxDdWqKglTSnT4pjx/8Tf7KxLpVoNoxV/i /MyuyU3cehd8E45HX8sLNLxdDYyXlk74c7cCdJMZEejTyURUVIti7kWIb1v47P6FTiO/ NExw== X-Gm-Message-State: AOAM532VjGIxY1PrD62fPxRbmlaTDq1+l0cn8JQYTN6y6/oo5v6PnCoV iYsx29MZHYSgu553pnpMTeaE/FGTLiDDt7H5LFA= X-Google-Smtp-Source: ABdhPJzs8Sgrtl0G0Fbx2PicdQii9jdyl4LIHspTU0ilO9/9CJX7+Z5HtXwWEK1yd3RdgdyxRVBZksJoTSw8v/TJQzw= X-Received: by 2002:a6b:7702:: with SMTP id n2mr3017075iom.1.1626352342646; Thu, 15 Jul 2021 05:32:22 -0700 (PDT) MIME-Version: 1.0 References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <1626179263-14645-1-git-send-email-fengchengwen@huawei.com> <04d6b19d-ba8e-7c12-b76c-d7e8c7e0a923@huawei.com> In-Reply-To: From: Jerin Jacob Date: Thu, 15 Jul 2021 18:01:56 +0530 Message-ID: To: Bruce Richardson Cc: Nipun Gupta , fengchengwen , "thomas@monjalon.net" , "ferruh.yigit@intel.com" , "jerinj@marvell.com" , "andrew.rybchenko@oktetlabs.ru" , "dev@dpdk.org" , "mb@smartsharesystems.com" , Hemant Agrawal , "maxime.coquelin@redhat.com" , "honnappa.nagarahalli@arm.com" , "david.marchand@redhat.com" , "sburla@marvell.com" , "pkapoor@marvell.com" , "konstantin.ananyev@intel.com" , Gagandeep Singh Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3] dmadev: introduce DMA device library 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 Thu, Jul 15, 2021 at 5:41 PM Bruce Richardson wrote: > > On Thu, Jul 15, 2021 at 11:16:54AM +0000, Nipun Gupta wrote: > > > > > > > -----Original Message----- > > > From: fengchengwen > > > Sent: Thursday, July 15, 2021 1:59 PM > > > To: Nipun Gupta ; thomas@monjalon.net; > > > ferruh.yigit@intel.com; bruce.richardson@intel.com; jerinj@marvell.com; > > > jerinjacobk@gmail.com; andrew.rybchenko@oktetlabs.ru > > > Cc: dev@dpdk.org; mb@smartsharesystems.com; Hemant Agrawal > > > ; maxime.coquelin@redhat.com; > > > honnappa.nagarahalli@arm.com; david.marchand@redhat.com; > > > sburla@marvell.com; pkapoor@marvell.com; konstantin.ananyev@intel.com; > > > Gagandeep Singh > > > Subject: Re: [PATCH v3] dmadev: introduce DMA device library > > > > > > On 2021/7/14 20:22, Nipun Gupta wrote: > > > > > > > > > > > >> +/** > > > >> + * A structure used to configure a virtual DMA channel. > > > >> + */ > > > >> +struct rte_dmadev_vchan_conf { > > > >> + uint8_t direction; > > > >> + /**< Set of supported transfer directions > > > >> + * @see RTE_DMA_MEM_TO_MEM > > > >> + * @see RTE_DMA_MEM_TO_DEV > > > >> + * @see RTE_DMA_DEV_TO_MEM > > > >> + * @see RTE_DMA_DEV_TO_DEV > > > >> + */ > > > >> + /** Number of descriptor for the virtual DMA channel */ > > > >> + uint16_t nb_desc; > > > >> + /** 1) Used to describes the port parameter in the device-to-memory > > > >> + * transfer scenario. > > > >> + * 2) Used to describes the source port parameter in the > > > >> + * device-to-device transfer scenario. > > > >> + * @see struct rte_dmadev_port_parameters > > > >> + */ > > > > > > > > There should also be a configuration to support no response (per Virtual > > > Channel), > > > > And if that is enabled, user will not be required to call 'rte_dmadev_completed' > > > API. > > > > This shall also be part of capability. > > > > > > Do you mean some silent mode? The application only needs to submit requests > > > to the > > > hardware. > > > > > > Could you briefly describe the working principles and application scenarios of > > > the > > > corresponding device? > > > > It is kind of a silent mode w.r.t. the command completion from QDMA. > > > > There could be level of synchronization in the applications at a higher level due > > To which QDMA status dequeue would not be necessary and be an overhead. > > In this mode extra data/bytes could be passed with DMA which would indirectly > > indicate if DMA is complete or not. > > > I'm wondering if such a setting could be per-device (i.e. per HW queue) > rather than per virtual channel? Something like this would be easier to > support in that way, because we could use different function pointers for > the fastpath operations depending on whether completions are to be tracked > or not. For example: only occasional descriptors will need completion > addresses specified in the "enqueue" calls, and the "submit" function would > also do any ring cleanup that would otherwise be done by "completed" call. > Having separate function calls would reduce the number of branches that > need to be evaluated in this mode, as well as simplifying the code. +1 to add in config param ie. for the device. > > /Bruce