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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 9BAC5C47094 for ; Mon, 7 Jun 2021 13:54:51 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 2836A610A8 for ; Mon, 7 Jun 2021 13:54:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2836A610A8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1E3774067E; Mon, 7 Jun 2021 15:54:48 +0200 (CEST) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) by mails.dpdk.org (Postfix) with ESMTP id 3C5E640147 for ; Mon, 7 Jun 2021 15:54:47 +0200 (CEST) Received: by mail-il1-f176.google.com with SMTP id v13so16163352ilh.13 for ; Mon, 07 Jun 2021 06:54:47 -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=3t7ChDLsMQfaZ4aEM+0/5cxOHj/oUApfmG0ZAyRZO5Y=; b=cBqH0siRJHef8ZxkghKBZynkJ5nNef6D4VOZlsywy7dBkh1ewDFRq9anfcN3b2BCXT xsvu543c32rFJj2d/fnFnEZ+BTIGGFqJBYrZzSfhnt4immK8Fkv/ViU9WBh5bxJuhtoD fY7GzRPxUQPEE8JSozuSNxpbf6dNmTcSGXFdX8FHFWcregsSQeX27G/POzySsm28PN/V 3uds+mE9uZxjI4cdz6Mt4tPJ44XZmb6WmA4NNK0zjj3rlk8vzl3/Z1dY7r8eEoFF8IhR /4akOz4hAql+IE6Rz3c7Yi/NsLtXYbAMjpVGy0bxg6SnOqNtjKyhUV+2zcrQhURZnZXE rw7g== 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=3t7ChDLsMQfaZ4aEM+0/5cxOHj/oUApfmG0ZAyRZO5Y=; b=Gg05r+ctV85rY/CsCXHknoYkkhy8NBzpfw8ikIlsdwO8rOTucc2/t7jkAgb4jz2DzZ dr4OJkg4ICQjjXtWweYp3T5miUf1yBKS3eqluviKQ9HqW1/+1SbQdXooMJfZF+uojdbU rp1va7PZtG6biygSBBZ4DNSIcJxk7efnumyNjJHIV2Skn2I2GwCA0c2eaYT3ZBnOigwr E7P0rGjmSI6Kf+GkCq4+gWqV2st7J76WGu60Y7m9FkeLSpW50Jx5/gWEnswz27vxFhOO qSG2GG/gGy/8HOvJp3PMVxYPr+wXFiwq1zsrBzG+NqEGdU51WXd7Cf9+pFmbxvtpACRG iTxA== X-Gm-Message-State: AOAM5334L87scwGELbm+n29hb0FNOuIjfi5TmYSkGhpE1SOk0f4EzWzf JvFITI0mXdoQOsgYkXnFPZr8a2lAoR5YlAb5vHA= X-Google-Smtp-Source: ABdhPJw3ziSk7qA7d1le63lCCVFWcwI84s1bJejuYsZH6k7bIPFCrr+J0g6553Iwd69hL2ZhjDU5/zi4LZJatV0vsEQ= X-Received: by 2002:a05:6e02:1a6a:: with SMTP id w10mr15746462ilv.130.1623074086480; Mon, 07 Jun 2021 06:54:46 -0700 (PDT) MIME-Version: 1.0 References: <20210602203531.2288645-1-thomas@monjalon.net> <3716354.mlbyQRhZUS@thomas> In-Reply-To: <3716354.mlbyQRhZUS@thomas> From: Jerin Jacob Date: Mon, 7 Jun 2021 19:24:30 +0530 Message-ID: To: Thomas Monjalon Cc: Honnappa Nagarahalli , Andrew Rybchenko , "Yigit, Ferruh" , dpdk-dev , Elena Agostini , David Marchand , nd , "Wang, Haiyue" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] gpudev: introduce memory 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 Mon, Jun 7, 2021 at 4:13 PM Thomas Monjalon wrote: > > 07/06/2021 09:20, Wang, Haiyue: > > From: Honnappa Nagarahalli > > > If we keep CXL in mind, I would imagine that in the future the devices on PCIe could have their own > > > local memory. May be some of the APIs could use generic names. For ex: instead of calling it as > > > "rte_gpu_malloc" may be we could call it as "rte_dev_malloc". This way any future device which hosts > > > its own memory that need to be managed by the application, can use these APIs. > > > > > > > "rte_dev_malloc" sounds a good name, > > Yes I like the idea. > 2 concerns: > > 1/ Device memory allocation requires a device handle. > So far we avoided exposing rte_device to the application. > How should we get a device handle from a DPDK application? Each device behaves differently at this level. In the view of the generic application, the architecture should like < Use DPDK subsystem as rte_ethdev, rte_bbdev etc for SPECIFIC function > ^ | < DPDK driver> ^ | An implementation may decide to have "in tree" or "out of tree" drivers or rte_device implementaion. But generic DPDK applications should not use devices directly. i.e rte_device need to have this callback and mlx ethdev/crypto driver use this driver to implement public API. Otherwise, it is the same as rawdev in DPDK. So not sure what it brings other than raw dev here if we are not taking the above architecture. > > 2/ Implementation must be done in a driver. > Should it be a callback defined at rte_device level? IMO, Yes and DPDK subsystem drivers to use it. > > > then looks like we need to enhance the > > 'struct rte_device' with some new ops as: > > > > eal: move DMA mapping from bus-specific to generic driver > > > > https://patchwork.dpdk.org/project/dpdk/patch/20210331224547.2217759-1-thomas@monjalon.net/ > > Not sure the above patch is a good idea. > Let's discuss this DMA detail later :) > > >