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 E879AA0C45; Sat, 18 Sep 2021 14:19:14 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7776A40041; Sat, 18 Sep 2021 14:19:14 +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 733F74003D for ; Sat, 18 Sep 2021 14:19:12 +0200 (CEST) Received: by mail-io1-f53.google.com with SMTP id y197so1980144iof.11 for ; Sat, 18 Sep 2021 05:19: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; bh=qbaF1quU4nO8P/PgizHc7/UXqQ34hHPFoCtJy+BF7CU=; b=Kgt5uQlQ9MmZMBr/r3Iit6dhKcZTUN3yXqV4TM8Eoy7igbcuSMEhnH4Wdxn/Rtr/Vo XVu8jXi/9thQKH4Cg2wADkiiRKmaYOr0BWkWrLJX9+pPlGmijwknoa36eh1rGfedE1hF Mv7T2Hhe9tQ2vKceNyPJv7A8Ciou+baEUWMFlRcb+3kiqMsamXTAoYC9Z+UuyACASSD3 t1Rw9Wuk8wGA46QSAODLxdOxJqF41Si3ZAscY+3ks4YMXsEEV74e7NEFLeAhXqBYUPHd KHitQTmtFniB96K2Hy1X/shWvxeL/j8qWfEVSPMpgnBzFWIzrDD072URZ4UX8m+cv2iz VeIA== 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=qbaF1quU4nO8P/PgizHc7/UXqQ34hHPFoCtJy+BF7CU=; b=BW8r9RH8i1eYPmQpK89lYCJOwIn1IoaPLjJCNLpugr7UbqZKUHWLEN81xl0/JK0WjP NcNmcjsahwUmjeNFS7Vmb7aMoUx3GKr0jSFLWsLnkTmqgD3RqutSakeWSTTYY+DDaVdu hqeAvxsHrJu9byD5iz0q4Hy0OM8EJ2O4aeZOgrEElmNVyGZhA2xKXEVNDuNtYEtRn57j BJ1OAIWCiLQE8mEvKQBEXejNm38G9RdC1dzauaL2NpbE4VxqkFpO8z3Adj1IUttkR4Ua cTciMnyIpvSKAKqX6I7LB85nV5F51+GuIjw//OfIJxY6cjGNAZ39XlcPlwzyb8j1mrOv QQSA== X-Gm-Message-State: AOAM5312sIgfgBU+3VPE2U0KSDUBYv3lTWnyZXz3nkG4aZovrwLQqiW9 DCl8dzqMiPTQNdab9n3gZLW0b+X9/klIThOmd+4= X-Google-Smtp-Source: ABdhPJyrPlS8RpLX4LziO4RqDBsQhnaJQTmAjBg9lvJm2G/akfO0+tAFkWl4EEGghKktrT4emtfO5JhCx664XA2AhDI= X-Received: by 2002:a5e:c701:: with SMTP id f1mr995381iop.185.1631967551633; Sat, 18 Sep 2021 05:19:11 -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: Sat, 18 Sep 2021 17:48:44 +0530 Message-ID: To: "Pai G, Sunil" Cc: "Richardson, Bruce" , dpdk-dev , "Walsh, Conor" , "Laatz, Kevin" , fengchengwen , Jerin Jacob , Satananda Burla , Radha Mohan Chintakuntla , "Hu, Jiayu" 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 Fri, Sep 17, 2021 at 8:07 PM Pai G, Sunil wrote: > > Hi Jerin, HI Sunil, > > > > > > > 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. > > Yes, this is true. We want to avoid scenarios where only parts of packets could be enqueued. What are those scenarios, could you share some descriptions of them. What if the final or any segment fails event the space is available. So you have to take care of that anyway. RIght? > > > > > 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. > > Here is an example of how the burst capacity API will be potentially used in the app(OVS): > http://patchwork.ozlabs.org/project/openvswitch/patch/20210907120021.4093604-2-sunil.pai.g@intel.com/ > Although commented out , it should still provide an idea of its usage. > > Thanks and regards, > Sunil >