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 ECD48A0C45; Wed, 22 Sep 2021 09:56:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B80BD41196; Wed, 22 Sep 2021 09:56:59 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id 8C4424069E for ; Wed, 22 Sep 2021 09:56:58 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10114"; a="210777404" X-IronPort-AV: E=Sophos;i="5.85,313,1624345200"; d="scan'208";a="210777404" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2021 00:56:57 -0700 X-IronPort-AV: E=Sophos;i="5.85,313,1624345200"; d="scan'208";a="702107115" Received: from donalmur-mobl.ger.corp.intel.com (HELO bricha3-MOBL.ger.corp.intel.com) ([10.252.8.128]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 22 Sep 2021 00:56:55 -0700 Date: Wed, 22 Sep 2021 08:56:50 +0100 From: Bruce Richardson To: fengchengwen Cc: Jerin Jacob , "Pai G, Sunil" , "Hu, Jiayu" , dpdk-dev , "Walsh, Conor" , "Laatz, Kevin" , Jerin Jacob , Satananda Burla , Radha Mohan Chintakuntla Message-ID: References: <8622d4b44e8e4b2e90a137a691f0c0a6@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v3 2/8] dmadev: add burst capacity API 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 Wed, Sep 22, 2021 at 09:51:42AM +0800, fengchengwen wrote: > On 2021/9/22 2:11, Jerin Jacob wrote: > > On Tue, Sep 21, 2021 at 10:42 PM Pai G, Sunil wrote: > >> > >> Hi Jerin, > >> > >> > >> > >>>>> To understand it better, Could you share more details on feedback > >>>>> mechanism on your application enqueue > >>>>> > >>>>> app_enqueue_v1(.., nb_seg) > >>>>> { > >>>>> /* Not enough space, Let application handle it by > >>>>> dropping or resubmitting */ > >>>>> if (rte_dmadev_burst_capacity() < nb_seg) > >>>>> return -ENOSPC; > >>>>> > >>>>> do rte_dma_op() in loop without checking error; > >>>>> return 0; // Success > >>>>> } > >>>>> > >>>>> vs > >>>>> app_enqueue_v2(.., nb_seg) > >>>>> { > >>>>> int rc; > >>>>> > >>>>> rc |= rte_dma_op() in loop without checking error; > >>>>> return rc; // return the actual status to application > >>>>> if Not enough space, Let application handle it by dropping or > >>>>> resubmitting */ } > >>>>> > >>>>> Is app_enqueue_v1() and app_enqueue_v2() logically the same from > >>>>> application PoV. Right? > >>>>> > >>>>> If not, could you explain, the version you are planning to do for > >>>>> app_enqueue() > >>>> > >>>> The exact version can be found here : > >>>> > >>> http://patchwork.ozlabs.org/project/openvswitch/patch/20210907120021.4 > >>>> 093604-2-sunil.pai.g@intel.com/ Unfortunately, both versions are not > >>>> same in our case because of the SW fallback we have for ring full scenario's. > >>>> For a packet with 8 nb_segs, if the ring has only space for 4 , we > >>>> would avoid this packet with app_enqueue_v1 while going ahead with an > >>> enqueue with app_enqueue_v2, resulting in a mix of DMA and CPU copies > >>> for a packet which we would want to avoid. > >>> > >>> Thanks for RFC link. Usage is clear now, Since you are checking the space in > >>> the completion handler, I am not sure, what is hard to get the remaining > >>> space, Will following logic work to find the empty space. If not, please discuss > >>> the issue with this approach. I am trying to avoid yet another fastpath API > >>> and complication in driver as there is element checking space in the submit > >>> queue and completion queue at least in our hardware. > >>> > >>> max_count = nb_desc; (power of 2) > >>> mask = max_count - 1; > >>> > >>> for (i = 0; I < n; i++) { > >>> submit_idx = rte_dma_copy(); > >>> } > >>> rc = rte_dma_completed(…, &completed_idx..); > >>> space_in_queue = mask - ((submit_idx – completed_idx) & mask); > >>> > >> > >> Unfortunately, space left in the device (as calculated by the app) still can mean there is no space in the device :| > >> i.e its pmd dependent. > > > > I did not pay much attention to Jiayu's reply as I did not know what is DSA. > > Now I searched the DSA in ml, I could see the PMD patches. > > > > If it is PMD limitation then I am fine with the proposed API. > > > > @Richardson, Bruce @Laatz, Kevin @feng Since it is used fastpath, Can > > we move to fastpath handler and > > remove additional check in fastpath from common code like other APIs. > > +1 for move to fastpath. > Will move in next revision.