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 C5FC2A0C45; Tue, 21 Sep 2021 18:59:27 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4315C40151; Tue, 21 Sep 2021 18:59:27 +0200 (CEST) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by mails.dpdk.org (Postfix) with ESMTP id 2C4504003C for ; Tue, 21 Sep 2021 18:59:26 +0200 (CEST) Received: by mail-io1-f47.google.com with SMTP id b10so28066902ioq.9 for ; Tue, 21 Sep 2021 09:59:26 -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=znc+LDjiPkRXMLjsspogQugMH0pdqWZPzbFS9JVBqFA=; b=kNwRjpCl5uldCiYnByOkm22Pmvm9K2qPy/XI705BXsEPB+qB7cyP+bKl5IDCwbJXp7 5HNNwJ9dCzqcLocxWA5FGSW2Yu7nMJ5s4eZbh3p6kyBLtl+5XLW1ADEXajLWA3beI0wR mVE04JdjabcGPA7tK5Vj+JVOE5XvT9D93OLueXF4t++gLLEtks/9KK2bQhMv6L4/AZ6T nBuH2Ja3VWPXxxp4TChCNRfHBpT1uxr1CnnpGKeqUyw8Ho/4uEqC9zrExSnbUXLLyd2k xbAZ3gJ5HhBy7yPHU0UQTmv2ZINrG+eLvaFEJ+0vf+HWF6c9e1yCEvalG7IPrIoMAoqT 8S4g== 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=znc+LDjiPkRXMLjsspogQugMH0pdqWZPzbFS9JVBqFA=; b=bb6prCgro7+zXcCp8pHXBusjWBcl+9O3RGG7rLMHshlW+XqEm7yg6GFUoKD/dGaGZH TJOkX/Cj6d7R4RqDol1gXT/+AAFNqjYJsTVU1rLXJVmHYCH1ifh5bX/5rqleRs5V24/L mCETLxhFoJciDbACZbfteDdnIPKZArpvn81Q4ygRHhrZUk7xHaThgs1jwlldev6RC5p8 cHnvwC92Ufxk5Rbi6DXGIcIh+seVJ+lMTIHLo7uGxj6Pn3OwAkL3Lm21rLP5LXdnEP68 dqqB/1dRRkYgwisGVIlQL3wjwAHP6/D9hFisw1WMlGwEyONL5JrkU4U6Mdl3IOQ9chbC p2Tw== X-Gm-Message-State: AOAM533Y0fRJl9H4QAItAM/fk0GbkJoBRqTM4caIRnoqp9HKyHmOiH4v 0HP35aQAtBhHmMMMPUZUylDkpVDp3jnINg1i49M= X-Google-Smtp-Source: ABdhPJxL0AWQ0Ibfm/fDBZSO3WbkWzBkAtOKj96L8NWdTAXuCspjbRoZ4Vx7faTlRiZDiQPP4LOh+JUkawnMe4jOUEE= X-Received: by 2002:a05:6602:1543:: with SMTP id h3mr802312iow.123.1632243565372; Tue, 21 Sep 2021 09:59:25 -0700 (PDT) MIME-Version: 1.0 References: <20210826183301.333442-1-bruce.richardson@intel.com> <20210907164925.291904-1-bruce.richardson@intel.com> <20210907164925.291904-3-bruce.richardson@intel.com> <8622d4b44e8e4b2e90a137a691f0c0a6@intel.com> In-Reply-To: From: Jerin Jacob Date: Tue, 21 Sep 2021 22:28:58 +0530 Message-ID: To: "Pai G, Sunil" Cc: "Hu, Jiayu" , "Richardson, Bruce" , dpdk-dev , "Walsh, Conor" , "Laatz, Kevin" , fengchengwen , 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 Tue, Sep 21, 2021 at 9:05 PM Pai G, Sunil wrote: > > Hi Jerin, > > > > > > > > The fact is that it's very hard for apps to calculate the > > > > > available space of a > > > > DMA ring. > > > > > > > > Yes, I agree. > > > > > > > > My question is more why to calculate the space per burst and > > > > introduce yet another fastpath API. > > > > For example, the application needs to copy 8 segments to complete a > > > > logical copy in the application perspective. > > > > In case, when 8th copy is completed then only the application marks > > > > the logical copy completed. > > > > i.e why to check per burst, 8 segments are available or not? Even i= t > > > > is available, there may be multiple reasons why any of the segment > > > > copies can fail. So the application needs to track all the jobs com= pleted or > > not anyway. > > > > Am I missing something in terms of vhost or OVS usage? > > > > > > > > > > For the packets that do not entirely fit in the DMA ring , we have a = SW copy > > fallback in place. > > > So, we would like to avoid scenario caused because of DMA ring full w= here > > few parts of the packet are copied through DMA and other parts by CPU. > > > Besides, this API would also help improve debuggability/device > > introspection to check the occupancy rather than the app having to manu= ally > > track the state of every DMA device in use. > > > > 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 |=3D rte_dma_op() in loop without checking error; > > return rc; // return the actual status to application if N= ot 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.4093604-2-sunil.pai.g@intel.com/ > Unfortunately, both versions are not same in our case because of the SW f= allback 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 =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) & mas= k); > > > > Thanks and regards, > Sunil >