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 9B6B0A0C41; Thu, 24 Jun 2021 10:05:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1EA9640141; Thu, 24 Jun 2021 10:05:46 +0200 (CEST) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by mails.dpdk.org (Postfix) with ESMTP id 104594003C for ; Thu, 24 Jun 2021 10:05:45 +0200 (CEST) Received: by mail-io1-f50.google.com with SMTP id b14so6735756iow.13 for ; Thu, 24 Jun 2021 01:05:44 -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:content-transfer-encoding; bh=ndC4+8F8b6SEAoutGxhZq1Q0Md7OcYP5UNdvR2tXihc=; b=RJb6ckOfa3Y4TpbajJkgI5TOxsI3aBxWvg6bcxRphsvH5opdyC7A/cgIDDWuRMJp57 7R4e2oTTof31YhDt5N0c3nwcPcLA9RzLd2onQ1idCGQeQq1ADRjyZWQTquw5OQG2xnpt 9ol9s3Q86HLJsF9az0QLK+K47djjpsrjf8V5gV2SLVJHc4qBiHKGwcYczCFh8XAYbk3v n+lUrOFLefU2FVJCufKPJAifyAdOFhxPH6Mo1LVi9fR9L2VihDIXHYSEgwa7GjbYniu/ ukZW+6xE//vZ4BWlZedvKo3aG2SQKlMII1fsMQu+DGlcNWyGfsqCIaL2dMCCzw/1yovU cp/g== 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:content-transfer-encoding; bh=ndC4+8F8b6SEAoutGxhZq1Q0Md7OcYP5UNdvR2tXihc=; b=FLkf4gwpMmsPtAqvfTYJGJWShnOOfwlXWkr6hY1Mttj8m5KhI58Clk2+Qc1zYsfTgX HRGv3IEulbRYSUSl40jMHt6rcv/N0rVDG+JXuRAdh1DaMIy1MzzwrmDGFeUNaZIS0OvL W3Yuw0tqfWD1+MKM1rOg/fZSlVJ8sOojJlbNfh16ewWYqNtrclcchZ80a8yrYJpJop2l DLp5EQY0ZpIzJoq3KVd1/sBEhXr0iXKNCLWz/glXwPpoVs/KwGElhEbqxbrIeApHBq4w AeFBhy6eDjW53MIedE1Ol6TXw9yf10RW6/oheR1GfsxKdbhVxosMcTG5D/uGb23ZhWTb YOhA== X-Gm-Message-State: AOAM531iys2qaSe+BgJaZcCQ6vWYLgUFEq8I1drks9ylSmZ9Jfq84WBL +JsUy4+wmhXlIzF1vmRUIVb6DZeV9lgAUmhBAqU= X-Google-Smtp-Source: ABdhPJwSTlUNOmlreWNupY7WoZShc1eyfj+JeJwIRjZHq1ldyvtBCeRF8VnK7QIFx04N1YhegQ1tDUIlLgGT3hZUW2Y= X-Received: by 2002:a05:6638:12cd:: with SMTP id v13mr3499102jas.104.1624521944306; Thu, 24 Jun 2021 01:05:44 -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> <98CBD80474FA8B44BF855DF32C47DC35C6188F@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C6188F@smartserver.smartshare.dk> From: Jerin Jacob Date: Thu, 24 Jun 2021 13:35:17 +0530 Message-ID: To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: fengchengwen , Bruce Richardson , Thomas Monjalon , Ferruh Yigit , dpdk-dev , Nipun Gupta , Hemant Agrawal , Maxime Coquelin , Honnappa Nagarahalli , Jerin Jacob , David Marchand , Satananda Burla , Prasun Kapoor Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Thu, Jun 24, 2021 at 1:29 PM Morten Br=C3=B8rup wrote: > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob > > Sent: Thursday, 24 June 2021 09.03 > > > > On Wed, Jun 23, 2021 at 9:20 AM fengchengwen > > wrote: > > > > > > > > > > > > > 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 process_vm_readv system call can do more than many-to-one and one-to-= many. It allows copying three 4 MB source segments into four 3 MB destinati= on segments or vice versa. I don't know if that is really necessary to supp= ort. We only need to support sum of src seg len =3D=3D sum of dest seg len. That is only a DMA use case. This one used multiple use cases like storage etc. > > We should consider limiting the DMA device API to only provide functions = where we can present realistic DPDK application use cases. Otherwise it wil= l be like the NIC device API, were every NIC vendor adds all sorts of exoti= c functions, only to expose their new and shiny NIC features in DPDK. (I'm = exaggerating here - you get the point!) > > The main purpose of the DMA device API is to provide a common interface, = so an application can call the same function, regardless of the different u= nderlying hardware. > > If the API becomes too hardware specific, the API will just become a set = of wrappers to specific hardware, and the application will need to consider= which DMA device hardware is present and adapt its behavior accordingly. J= ust like RSS hash functions on the NICs; the application needs to adapt to = which RSS hash functions the underlying NICs support. There will be base APIs that work on all the HWs. We should not limit the API for advanced usage based on the capability. > > > -Morten >