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 1D755A0C45; Wed, 22 Sep 2021 18:36:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8DC4F411EC; Wed, 22 Sep 2021 18:36:35 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id 85826411A8 for ; Wed, 22 Sep 2021 18:36:33 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10115"; a="220441912" X-IronPort-AV: E=Sophos;i="5.85,314,1624345200"; d="scan'208";a="220441912" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2021 09:35:47 -0700 X-IronPort-AV: E=Sophos;i="5.85,314,1624345200"; d="scan'208";a="704085726" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.18.223]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 22 Sep 2021 09:35:42 -0700 Date: Wed, 22 Sep 2021 17:35:39 +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 08:56:50AM +0100, Bruce Richardson wrote: > 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. Follow-up question on this. If it's a fastpath function then we would not normally check for support from drivers. Therefore do we want to: 1. make it a mandatory function 2. add a feature capability flag Given that it's likely fairly easy for all drivers to implement, and it makes it easier for apps to avoid having to check a feature flag for, I'd tend towards option #1, but just would like consensus before I push any more patches. /Bruce