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 11A99A0C41; Thu, 24 Jun 2021 09:03:33 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CC91340141; Thu, 24 Jun 2021 09:03:32 +0200 (CEST) Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) by mails.dpdk.org (Postfix) with ESMTP id 2C0F84003C for ; Thu, 24 Jun 2021 09:03:32 +0200 (CEST) Received: by mail-il1-f173.google.com with SMTP id i13so868739ilu.4 for ; Thu, 24 Jun 2021 00:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4coTnpp2hV31Xs5M1aGDTArThsB9BwVBcITipIyxXKw=; b=EPT3ZgT1TxSSKyXocezkDHeq1v0LWdCmF5ipTYJ6i5Pfs4jlHVIRGhD3bagpoQ3vC4 o+VMEZmhmkydI8ZjA40HZ1eLscL/Iw6caRJpbBkP+dv09Fm8o6Pgs7nECCPaW/xsmIwf zI1JlQYJj3mZ6UgFWaz/17lXjiMZubDSofIlWTjyVBiBXBQStg8h3CIUfsjqnDFPTMG4 aDQ2QojT/BBlqySQ3r0d+iq/aSXXsy4nXNz4K/e4b3SZTv6lQLNpR4xeVK4KR7su9Mu2 9U9/gOSpS0l5u8C06LNi9jA0wHx0Y83+3VPjBZlXuFGED6jNTVYId83gBANomjfNlpbN 6SoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4coTnpp2hV31Xs5M1aGDTArThsB9BwVBcITipIyxXKw=; b=mRuaSh07tEMi2ZMnhi/XuCTMUM2KnOWaiFhq+qB8E+xOtIRNFTX8ExXSOfhKYEJuGn 3u30l8mRxXMdKnT14Av6+gsnEE8FSrfz8SrzeKEsK5kP9jrLiSvXBggYYJIXFklqPG/P VTeBsKkyIVlLQ7s86TwqWpOrS8+Rixx53h1miSxUvOPwIDLdMVc7VlL8GdFjSuW2kkkS mfT/LU5FVZ0UTPyhfvavQa7RxWN1VSLEjs8tE83T9ZHTKoksK0GEfLwZuzO67+NKedO7 nLhlkWMlLVXIWAXHgYIYiWZLXM2hEv79svic7a/YQQwzaTn++xbNHAbD/VA4GNeMTBsI BIJQ== X-Gm-Message-State: AOAM532k34jJ3xM9m5d6wAvU8LhEODxmSStifF1mGAncqfjdKNyzsEGi mw8t5OjAmisL2vQZ08s28Y010aNkFiQgNoMmE6s= X-Google-Smtp-Source: ABdhPJwX8Wuef5UQRIf60kHfL6IYkA7uzhuesjUKdMbtv2k66dyhV5f4a3tW0Ecms08lbguSpe99C/bLcBpXpaCKZyw= X-Received: by 2002:a05:6e02:e0e:: with SMTP id a14mr2495263ilk.294.1624518211539; Thu, 24 Jun 2021 00:03:31 -0700 (PDT) MIME-Version: 1.0 References: <1623763327-30987-1-git-send-email-fengchengwen@huawei.com> <25d29598-c26d-8497-2867-9b650c79df49@huawei.com> <3db2eda0-4490-2b8f-c65d-636bcf794494@huawei.com> In-Reply-To: <3db2eda0-4490-2b8f-c65d-636bcf794494@huawei.com> From: Jerin Jacob Date: Thu, 24 Jun 2021 12:33:05 +0530 Message-ID: To: fengchengwen Cc: Bruce Richardson , Thomas Monjalon , Ferruh Yigit , dpdk-dev , Nipun Gupta , Hemant Agrawal , Maxime Coquelin , Honnappa Nagarahalli , Jerin Jacob , David Marchand , Satananda Burla , Prasun Kapoor , =?UTF-8?Q?Morten_Br=C3=B8rup?= Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC PATCH] dmadev: introduce DMA device library 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, Jun 23, 2021 at 9:20 AM fengchengwen wrote: > > >> > >> So I prefer following prototype: > >> uint16_t rte_dmadev_completed(uint16_t dev_id, dma_cookie_t *cookie, uint16_t nb_cpls, bool *has_error) > >> -- nb_cpls: indicate max process operations number > >> -- has_error: indicate if there is an error > >> -- return value: the number of successful completed operations. > >> -- example: > >> 1) If there are already 32 completed ops, and 4th is error, and nb_cpls is 32, then > >> the ret will be 3(because 1/2/3th is OK), and has_error will be true. > >> 2) If there are already 32 completed ops, and all successful completed, then the ret > >> will be min(32, nb_cpls), and has_error will be false. > >> 3) If there are already 32 completed ops, and all failed completed, then the ret will > >> be 0, and has_error will be true. > >> uint16_t rte_dmadev_completed_status(uint16_t dev_id, dma_cookie_t *cookie, uint16_t nb_status, uint32_t *status) > >> -- return value: the number of failed completed operations. > > > > > > > > In typical storage use cases etc, Sometimes application need to > > provide scatter-gather list, > > At least in our hardware sg list gives a "single completion result" > > and it stops on the first failure to restart > > the transfer by application. Have you thought of scatter-gather use > > case and how it is in other HW? > > cookie and request are in a one-to-one correspondence, whether the request is a single or sg-list. > Kunpeng9x0 don't support sg-list, I'm still investigating other hardware. > > The above 'restart the transfer by application' mean re-schedule request (and have one new cookie) or > just re-enable current failed request (this may introduce new API) ? > > > > > prototype like the following works for us: > > rte_dmadev_enq_sg(void **src, void **dest, unsigned int **length, int > > nb_segments, cookie, ,,,) > > OK, we could define one scatter-list struct to wrap src/dest/length. Inspired from following system call [1] [1] https://man7.org/linux/man-pages/man2/process_vm_readv.2.html I propose the following style syntax for the sg list struct rte_dma_iovec { void *iov_base; /* Starting address */ size_t iov_len; /* Number of bytes to transfer */ }; rte_dmadev_enq_sg(const struct rte_dma_iovec *src_iov, unsigned int srcvcnt, const struct rte_dma_iovec *dst_iov, unsigned int dstvcnt, ....) The reason for separating iov_len for src and dest is the many to one case and one to many cases. Example: Copy of Multiple 2MB of 15 source segments to one 30MB dest. Quite use full in storage use cases. > > > > > > >> > >> The application use the following invocation order when polling: > >> has_error = false; // could be init to false by dmadev API, we need discuss > >> ret = rte_dmadev_completed(dev_id, &cookie, bust_size, &has_error); > >> // process successful completed case: > >> for (int i = 0; i < ret; i++) { > >> } > >> if (unlikely(has_error)) { > >> // process failed completed case > >> ret = rte_dmadev_completed_status(dev_id, &cookie, burst_size - ret, status_array); > >> for (int i = 0; i < ret; i++) { > >> // ... > >> } > >> } > >> > >> > >>> > >>> This two-function approach also allows future support for other DMA > >>> functions such as comparison, where a status value is always required. Any > >>> apps using that functionality would just always use the "_status" function > >>> for completions. > >>> > >>> /Bruce > >>> > >>> . > >>> > >> > > > > . > > >