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 C3D6AA0C41; Thu, 15 Jul 2021 11:30:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A51EB4014D; Thu, 15 Jul 2021 11:30:29 +0200 (CEST) Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) by mails.dpdk.org (Postfix) with ESMTP id 1518F40143 for ; Thu, 15 Jul 2021 11:30:29 +0200 (CEST) Received: by mail-il1-f172.google.com with SMTP id e2so4403678ilu.5 for ; Thu, 15 Jul 2021 02:30:29 -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=XXjhDS/XHfNB1LSUbmBnBXRwaLQNMNCMbNypv/YdM1Q=; b=BFKv1HNtziVQfvx+LPMCUVzO4dbBKMmZilLwx8O/FUK5DN2odnIKWXprfgxQ5Zr6QH ZKN9jwBdEUjbvpStB88+9ruEVFpSMpc3JPuwwFzEWisXRhRlhECCh44VUlwpXMOUs3FQ JBmwCVLHm/jY9Pxe3NrQUOYqkzkR5IU9vIqauNFkqgorWT6Q9K2y/NyES3FSp25xqdzj 10B3b4oNdTVVwa5WSPrYx8oqnDK0FmpKRWX66Vp3HqTDENEJlwXOcG4X1cyQQX+cb+MC 4SyvhD+/Tew4fiRE3zqFCpt4prmm8gEULtKGpNVSlQ/D1kYCqrTtUcEWwYbX5lUn2s3z Qyjg== 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=XXjhDS/XHfNB1LSUbmBnBXRwaLQNMNCMbNypv/YdM1Q=; b=rDhtFIw6AYKDifYLaIyfpg7t12dD0hS/v8mSr6FE/U8jbKc5tC6WEbGv/ErA6eTKPa m+6JIowklVSGSgYDyc+5IW3QkXM5PRlnJyJizBfKWsL5s0h59xV7qS1VDtNWvtqI49mp 6336zthuUCVlX6ZAELawY0HLJUngwoacXbDx08rCYpLNZxsnHeNS9oEFXMNAy3Hn2XEz 4OU1h2VY0mLBdWKCLWZYFVoyF6z2v0nyIYEjCcSjxkxWYV4iUYXwrqrBSVx6Zuf+PbAx e0BqRNYpD5DKilYJJL9T5qtVr9XGVZMkhQAj7CN6gj5/zwVR8Ee3AbV5jQBGcqx1Ik1C 1/eQ== X-Gm-Message-State: AOAM533QZfJM8B0w7gA0iA9osWFvCmT8V8m+LMX5HUGoCGvQBf/DoZfW KYg/VYxXaVU55EMlr4+42nnIdwvq8s2i9TMXeNE= X-Google-Smtp-Source: ABdhPJyAkiJp+iis+e7O1sueqW2R2M53R3/LtgbMIfGZHbzkfTz98N6YAXyoTWH8VnOyc12KmHrUPWL3AJ6fJ9I/nxk= X-Received: by 2002:a92:c5c5:: with SMTP id s5mr1901494ilt.271.1626341428397; Thu, 15 Jul 2021 02:30:28 -0700 (PDT) MIME-Version: 1.0 References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <1626179263-14645-1-git-send-email-fengchengwen@huawei.com> In-Reply-To: From: Jerin Jacob Date: Thu, 15 Jul 2021 15:00:01 +0530 Message-ID: To: Bruce Richardson Cc: Chengwen Feng , Thomas Monjalon , Ferruh Yigit , Jerin Jacob , Andrew Rybchenko , dpdk-dev , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Nipun Gupta , Hemant Agrawal , Maxime Coquelin , Honnappa Nagarahalli , David Marchand , Satananda Burla , Prasun Kapoor , "Ananyev, Konstantin" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3] 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, Jul 15, 2021 at 2:33 PM Bruce Richardson wrote: > > On Thu, Jul 15, 2021 at 12:40:01PM +0530, Jerin Jacob wrote: > > ) > > a > > > > On Tue, Jul 13, 2021 at 6:01 PM Chengwen Feng wrote: > > > > > > This patch introduce 'dmadevice' which is a generic type of DMA > > > device. > > > > > > The APIs of dmadev library exposes some generic operations which can > > > enable configuration and I/O with the DMA devices. > > > > > > Signed-off-by: Chengwen Feng > > > > Thanks for v3. Seems like all major items as covered. Some more > > comments below inline. > > > > I would suggest v4 to split the patch like (so that we can review and > > ack each patch) > > 1) Only public header file with Doxygen inclusion, (There is a lot of > > Doxygen syntax issue in the patch) > > 2) 1 or more patches for implementation. > > > > One additional follow-up comment on flags below. > > /Bruce > > > > > > diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h > > > new file mode 100644 > > > index 0000000..f6cc4e5 > > > > + enum rte_dmadev_port_type port_type; > > missing doxgen comment for this. > > > + union { > > > + /** For PCIE port > > > + * > > > + * The following model show SoC's PCIE module connects to > > > + * multiple PCIE hosts and multiple endpoints. The PCIE module > > > + * has an integrate DMA controller. > > > + * If the DMA wants to access the memory of host A, it can be > > > + * initiated by PF1 in core0, or by VF0 of PF0 in core0. > > > + * > > > + /** The pasid filed in TLP packet */ > > > + uint64_t pasid : 20; > > > + /** The attributes filed in TLP packet */ > > > + uint64_t attr : 3; > > > + /** The processing hint filed in TLP packet */ > > > + uint64_t ph : 2; > > > + /** The steering tag filed in TLP packet */ > > > + uint64_t st : 16; > > > > We don't support a few attributes like passid, ph, st. Do we need > > the capability of this? or ignore this. In either case, please update the doc. > > > > We also support additional flags for allocating LLC flag. > > This is a hint to DMA engine that the cache blocks should be allocated > > in the LLC (if they were not already). > > When the MEM pointer is a destination in DMA operation, the referenced > > cache blocks are allocated into the cache as part of completing the > > DMA (when not already present in the LLC) > > this is helpful if software has to access the data right after dma is completed. > > > > Could you add bit or flag for the same? > > > > I wonder if this is the best location for such a flag for LLC vs memory > writes. It would also apply to memory-to-memory transactions, not just for > those done to PCI devices. Ack. it can be used for MEM to MEM > As well as that, I think any flag should default > to "on" rather than "off" since writing to cache rather than DRAM is > generally the desired behaviour, I would think. I think, keeping it is "allocate in LLC" on all transfer will not be good. As large transters polute the LLC and dataplane may not touch the complete data only header. Also in device copy, Adding it LLC there is an additional cost unline MEM-MEM. So IMO, better to add the flag to allow to allocate to LLC as a HINT. > Should it be a per-operation flag, rather than per context? Yes. better it be per-operation as it is the hint. > >