From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0EA07C433F5 for ; Thu, 9 Sep 2021 08:16:24 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 7DC0061139 for ; Thu, 9 Sep 2021 08:16:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7DC0061139 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BA4F04067E; Thu, 9 Sep 2021 10:16:22 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 10A9240041 for ; Thu, 9 Sep 2021 10:16:20 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10101"; a="207832013" X-IronPort-AV: E=Sophos;i="5.85,279,1624345200"; d="scan'208";a="207832013" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2021 01:16:20 -0700 X-IronPort-AV: E=Sophos;i="5.85,279,1624345200"; d="scan'208";a="696139508" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.3.161]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 09 Sep 2021 01:16:16 -0700 Date: Thu, 9 Sep 2021 09:16:11 +0100 From: Bruce Richardson To: Jerin Jacob Cc: dpdk-dev , "Walsh, Conor" , "Laatz, Kevin" , fengchengwen , Jerin Jacob , Satananda Burla , Radha Mohan Chintakuntla , jiayu.hu@intel.com, sunil.pai.g@intel.com Message-ID: References: <20210826183301.333442-1-bruce.richardson@intel.com> <20210907164925.291904-1-bruce.richardson@intel.com> <20210907164925.291904-3-bruce.richardson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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. > # 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. /Bruce