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 53BABA0C45; Sat, 18 Sep 2021 14:12:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D0C6040041; Sat, 18 Sep 2021 14:12:53 +0200 (CEST) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) by mails.dpdk.org (Postfix) with ESMTP id 7FFCC4003D for ; Sat, 18 Sep 2021 14:12:52 +0200 (CEST) Received: by mail-io1-f42.google.com with SMTP id j18so15518524ioj.8 for ; Sat, 18 Sep 2021 05:12:52 -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=0qApEtpr+6+5h/tXWCPjKdommuhUKFizDoiRu4OLhuc=; b=q5Y83kKCHynWdYv4kOVwUkme7HF/ZrecPTqgh7XCtG9Wt5Baf3an6P5hdVQ56U5hTE FUHkCsmMne1cwUoLv3k/yFA/R1PFEfOlQ1lXsgbSuqTf5/1ZMM5qZdca+B6DccWHd9Xc wNWSbW4gPZjDW3s9rto84oD1dO6JqC1H61Vb7y/EzIup9vznjauFkqCBZn3aPFuAX+Ma hLDNO9QPBdmI3KSo+6uu2ZeSUQsOSv21DfkNfalDhdSeeGcXCyfsb0j93v6yBOt1TiCt 6ULK7wltQs2NLX5tMRByVS6NfX7HSfyfwOq3VYYGZ3LOhourKT/xp9J5cbI1CP3p19vM l/lQ== 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=0qApEtpr+6+5h/tXWCPjKdommuhUKFizDoiRu4OLhuc=; b=btNCgQ/2pxFdoR4MqlDiIznrlf4in0B2b92ChP3GJTPJVqINEVnHf/KYi4pNhjBcuB B0qjFU9ZOp9WDryh6mDE3i14AaVOrNowFgQtGMda976zxfk+OL3TxCqi+Fjfx5kvvd/Y PoOigkJRqbNHtpiOiV9FYDoESu5iOCQ8sARBW0dfGy9xaVT1ZwkpKQs9R7Wz/SLMlEs8 SBgek1BaPlm5XiVrXZY7SgxOz/eaCuU+xlc5Cyj9DJgabxqOQ2+RDQDgd+NthCxmYEIp 0Mrxf8hRjQe4APTsbxti0rCwhTbeOlRS4quaV1KVgrK7GQyqPpYkJo5vLBbhLvfvoTcw fB9g== X-Gm-Message-State: AOAM533ayICql/V/u7sW43qXy6iC50ci9h5A261QxfDfUsDGVKx3vNJt 2Qp0lXlpYFvKL/GUMRZGwhMt1Na0PmCn14ofbec= X-Google-Smtp-Source: ABdhPJyOkF5bFKr1oMx4YzD1f8YUY11JcsYO5nOfqCf/jJkwLSUZqWqUUhglGcKFX93fQuf2JX7pR4UKzCmXvU2KOJA= X-Received: by 2002:a6b:e410:: with SMTP id u16mr11778812iog.38.1631967171831; Sat, 18 Sep 2021 05:12:51 -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: <8622d4b44e8e4b2e90a137a691f0c0a6@intel.com> From: Jerin Jacob Date: Sat, 18 Sep 2021 17:42:25 +0530 Message-ID: To: "Hu, Jiayu" Cc: "Richardson, Bruce" , dpdk-dev , "Walsh, Conor" , "Laatz, Kevin" , fengchengwen , Jerin Jacob , Satananda Burla , Radha Mohan Chintakuntla , "Pai G, Sunil" 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 Sat, Sep 18, 2021 at 6:36 AM Hu, Jiayu wrote: > > Hi Jerin, > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Friday, September 17, 2021 9:55 PM > > To: Richardson, Bruce > > Cc: dpdk-dev ; Walsh, Conor ; > > Laatz, Kevin ; fengchengwen > > ; Jerin Jacob ; > > Satananda Burla ; Radha Mohan Chintakuntla > > ; Hu, Jiayu ; Pai G, Sunil > > > > Subject: Re: [dpdk-dev] [PATCH v3 2/8] dmadev: add burst capacity API > > > > 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. Hi Jiayu, Sunil, > 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 it is available, there may be multiple reasons why any of the segment copies can fail. So the application needs to track all the jobs completed or not anyway. Am I missing something in terms of vhost or OVS usage? > For DSA, the available space is decided by three factors: the number of available slots > in SW ring, the max batching size of a batch descriptor, and if there are available batch > descriptors. The first one is configured by SW, and apps can calculate it. But the second > depends on DSA HW, and the third one is hided in DSA driver which is not visible to apps. > Considering the complexity of different DMA HW, I think the best way is to hide all details > inside DMA dev and provide this check capacity API for apps. > > Thanks, > Jiayu > > > > > > > > > > # 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