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 24AF5A0C45; Wed, 22 Sep 2021 19:30:14 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B1004411EC; Wed, 22 Sep 2021 19:30:13 +0200 (CEST) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) by mails.dpdk.org (Postfix) with ESMTP id 3FF29411A8 for ; Wed, 22 Sep 2021 19:30:12 +0200 (CEST) Received: by mail-io1-f53.google.com with SMTP id y197so4347190iof.11 for ; Wed, 22 Sep 2021 10:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qb+1rbjed+o1jp4FKA3elOkFKgHDvO5FX25Z75cHejg=; b=lE7lieR8Jsb4FQ/yaFF9L3IbD96wUfvY6kHpFojtoOTOXKZyj2Q71d6WdfQrT9j57W hwVEydLIUUIaTcdHoRDh3b1YtDQWB96GtND2XDHmyDuztdCkJBDoT6NYGuq2PkLa3Cwd Ut7DdBpzynDfpZov0g15KEb3zKbT5cU9XPKr8n2ABOt/gmKuPV3uP0ys6Y1LybU531RC 3KqUtLYprPHUfdiBW7JLkhBkObVOEv+gcz/oOlAIl5SPLlombGL4WKg2E7O1zuKOdTr3 vdNUG84fuHdKIHRgfQ4v7AQNaPjXNxgeyc00VyTE+W//ly8snIqu0lJqnne5zCShnb5D DtTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qb+1rbjed+o1jp4FKA3elOkFKgHDvO5FX25Z75cHejg=; b=mNckXJrkFPd/hMyawfkNESMHHoqNXPUd8VMJs8d2j9M4+Av7YZw1+1nzaFonZC0/rY cuUizzGN1Js0Pr+PLzGRduVQfoXfH9ywASlP0XclTX6wtHRLvVoQvtYVR9bgU1cbV6QZ 2qxIp2XcMpMNxUulCxfM280cgqCMBIe455199JEdG0ufkLRaLtpt+vNNIy50QNxePe9M UwyDdNgcDch5f/+qcHZgrvRAb7BuqB9OaIoWicWFyrTl4IRdM+mfXTdrun4aaBLKRI7T qj28y3qKJfigKJCkWqa8XlWM1vXEGTy2TmeB0xRuHSouQzAOdmAkg9BFE3LIP9R4qbAe qyeA== X-Gm-Message-State: AOAM533RPtmAfEpyrhrDMUtoZ1gDxEcjtJ0SQNDBbBG8dOlL/mHPDUEW EfaKnKIL/sQyWO93g+Ur5t05JSvyhf78ky3MQMU= X-Google-Smtp-Source: ABdhPJxUFE1X2M6T6xekNfNhGJ8lyBhRr4YyZ02tvYXpQKrGr3GfBlJ548gBWR1xeO6kYP1qD5cmpD0V8DKZ3+0nqdY= X-Received: by 2002:a6b:3e84:: with SMTP id l126mr123009ioa.151.1632331811445; Wed, 22 Sep 2021 10:30:11 -0700 (PDT) MIME-Version: 1.0 References: <8622d4b44e8e4b2e90a137a691f0c0a6@intel.com> In-Reply-To: From: Jerin Jacob Date: Wed, 22 Sep 2021 22:59:44 +0530 Message-ID: To: Bruce Richardson Cc: fengchengwen , "Pai G, Sunil" , "Hu, Jiayu" , dpdk-dev , "Walsh, Conor" , "Laatz, Kevin" , Jerin Jacob , Satananda Burla , Radha Mohan Chintakuntla Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 10:06 PM Bruce Richardson wrote: > > 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 feedba= ck > > > >>>>> 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 |=3D rte_dma_op() in loop without checking error= ; > > > >>>>> return rc; // return the actual status to applicati= on > > > >>>>> if Not enough space, Let application handle it by dropping or > > > >>>>> resubmitting */ } > > > >>>>> > > > >>>>> Is app_enqueue_v1() and app_enqueue_v2() logically the same fro= m > > > >>>>> application PoV. Right? > > > >>>>> > > > >>>>> If not, could you explain, the version you are planning to do f= or > > > >>>>> app_enqueue() > > > >>>> > > > >>>> The exact version can be found here : > > > >>>> > > > >>> http://patchwork.ozlabs.org/project/openvswitch/patch/20210907120= 021.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 ful= l 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 wi= th an > > > >>> enqueue with app_enqueue_v2, resulting in a mix of DMA and CPU co= pies > > > >>> for a packet which we would want to avoid. > > > >>> > > > >>> Thanks for RFC link. Usage is clear now, Since you are checking t= he space in > > > >>> the completion handler, I am not sure, what is hard to get the re= maining > > > >>> 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 fa= stpath 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 =3D nb_desc; (power of 2) > > > >>> mask =3D max_count - 1; > > > >>> > > > >>> for (i =3D 0; I < n; i++) { > > > >>> submit_idx =3D rte_dma_copy(); > > > >>> } > > > >>> rc =3D rte_dma_completed(=E2=80=A6, &completed_idx..); > > > >>> space_in_queue =3D mask - ((submit_idx =E2=80=93 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 wha= t 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 API= s. > > > > > > +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. I think, if vhost using in that way then it needs to make it a mandatory function. > > /Bruce