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 E4499A0C46; Fri, 17 Sep 2021 15:55:35 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C7CF94114B; Fri, 17 Sep 2021 15:55:00 +0200 (CEST) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) by mails.dpdk.org (Postfix) with ESMTP id 97B1C4114B for ; Fri, 17 Sep 2021 15:54:58 +0200 (CEST) Received: by mail-io1-f41.google.com with SMTP id p80so5703437iod.10 for ; Fri, 17 Sep 2021 06:54:58 -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; bh=bDkL+wq5f4A9c7SBBg+DtFzCSSy1EJ0L/Ja+Qcyk+XU=; b=Bl3HsxrkT8HFPGdhRLJNG/spYoTnR4YdvbTFcZEOnkd2P61tQWR/6LFs6YBaItzpVa KXGsvCqtdXHIMIQnGQOuZAxzlK1/aFTKxSf7E6nElwMI+EzSJ3P6KsNQ2Q5NpmcKI7Qd 0Nr//BKFzWs3LzIaBXQrk7dDRpzeQ/Qq91s57Wn7pC3k80Df0PGdQdMB6/PKd4zd8kVq wfEr9qMGOGNklGkQMoW5y8s1h3DLpsJaI5n8/JdbK7D9CnX01LvbpzI3FfBJ8fjLprXT lMVp4/wssApya4GP8ZkUZHcXaxbBh4n14OZQXmqmtQ2W9N2WD7vtA/S1yzvWKyXOOuEb RCjA== 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; bh=bDkL+wq5f4A9c7SBBg+DtFzCSSy1EJ0L/Ja+Qcyk+XU=; b=n9DBhIUbevACPDZjSXDSdTpaw4PfWEp9YUDAfpjtwWT2/TIGhhHoQ2UXcl316C+nLW boNsXXXWdj9mFos6OO2KuixB9kZ8soy5Yc4i7k0ENS3mQlVqJSFJpDzUo/zJ8xBSymVE nfthbYiiTF4vLpgU2sDCirj2f5KipyLAg/zIoG2qcrPRyc2QnIfdguGjtu4c3+BjwGyx 5EqeGImjcYZY6rxJENJ1qqNqq0ZldxhyZENRAKZMBKhRaZxF9R9wBNs+4tH7Fd1X0dww nd/K4lv5xz7hI9YGECaIR9YOfQ54LZx6LUTDe+yMYDEMhZpE0pkT92X2kQ7+rfXHWsgS k7ng== X-Gm-Message-State: AOAM533FF9n0RCRQZgICnw3dd4KZ7w40sKtJUMi1tHneDxBohilha+Hv WkqT2xcaj1Jm6cVBj6wSGRZ/mXdjWVA9jkfGHTo= X-Google-Smtp-Source: ABdhPJzNIvOnHahtsOf4XZR2A5aSyfqkr/WAvHUEP3jJViAC025ifZF5VEYJdBiXRfohpCdvEL6CMIFAsLzIcupS4Ko= X-Received: by 2002:a05:6638:d85:: with SMTP id l5mr8897672jaj.2.1631886897228; Fri, 17 Sep 2021 06:54:57 -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> In-Reply-To: From: Jerin Jacob Date: Fri, 17 Sep 2021 19:24:30 +0530 Message-ID: To: Bruce Richardson Cc: dpdk-dev , "Walsh, Conor" , "Laatz, Kevin" , fengchengwen , Jerin Jacob , Satananda Burla , Radha Mohan Chintakuntla , Jiayu Hu , Sunil Pai G Content-Type: text/plain; charset="UTF-8" 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 Thu, Sep 9, 2021 at 1:46 PM Bruce Richardson wrote: > > On Wed, Sep 08, 2021 at 11:47:59PM +0530, Jerin Jacob wrote: > > On Tue, 7 Sep 2021, 10:25 pm Bruce Richardson, > > <[1]bruce.richardson@intel.com> wrote: > > > > From: Kevin Laatz <[2]kevin.laatz@intel.com> > > Add a burst capacity check API to the dmadev library. This API is > > useful to > > applications which need to how many descriptors can be enqueued in > > the > > current batch. For example, it could be used to determine whether > > all > > segments of a multi-segment packet can be enqueued in the same batch > > or not > > (to avoid half-offload of the packet). > > > > #Could you share more details on the use case with vhost? > > # Are they planning to use this in fast path if so it need to move as > > fast path function pointer? > > I believe the intent is to use it on fastpath, but I would assume only once > per burst, so the penalty for non-fastpath may be acceptable. As you point > out - for an app that really doesn't want to have to pay that penalty, > tracking ring use itself is possible. > > The desire for fast-path use is also why I suggested having the space as an > optional return parameter from the submit API call. It could logically also > be a return value from the "completed" call, which might actually make more > sense. > > > # Assume the use case needs N rte_dma_copy to complete a logical copy > > at vhost level. Is the any issue in half-offload, meaning when N th one > > successfully completed then only the logical copy is completed. Right? > > Yes, as I understand it, the issue is for multi-segment packets, where we > only want to enqueue the first segment if we know we will success with the > final one too. Sorry for the delay in reply. If so, why do we need this API. We can mark a logical transaction completed IFF final segment is succeeded. Since this fastpath API, I would like to really understand the real use case for it, so if required then we need to implement in an optimized way. Otherwise driver does not need to implement this to have generic solution for all the drivers. > > > # There is already nb_desc with which a dma_queue is configured. So if > > the application does its accounting properly, it knows how many desc it > > has used up and how many completions it has processed. > > Agreed. It's just more work for the app, and for simplicity and > completeness I think we should add this API. Because there are other > options I think it should be available, but not as a fast-path fn (though > again, the difference is likely very small for something not called for > every enqueue). > > > Would like to understand more details on this API usage. > > > Adding Sunil and Jiayu on CC who are looking at this area from the OVS and > vhost sides. See above. Sunil. Jiayu, Could you share the details on the usage and why it is needed. > > /Bruce