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 39365A0A0F; Fri, 4 Jun 2021 17:05:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1B5824068F; Fri, 4 Jun 2021 17:05:45 +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 4E3C840147 for ; Fri, 4 Jun 2021 17:05:43 +0200 (CEST) Received: by mail-il1-f176.google.com with SMTP id b9so9161130ilr.2 for ; Fri, 04 Jun 2021 08:05:43 -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=Z6a1wGdG7l77L3AQN5VjA/Lobs6OuBFqWivd/c5aWYE=; b=ZoWKbpwMS834iQYiuNk2oCyCvvS/+SmY8HTC+yvd//e9D9LGSUsAY4AZk7UcuE8vA+ 3fUbxNuTenErno0cRDPxbdsy5T+Df46v3U4lIsphgxFC9C08mO+c2I4wNwCYD4fZ2bRd vqKdQhpoFykQIanUA9kzj+dMIWkVlpdHmw2c9SzYKtx4pRTQ+f7zUJ5hA5SzKpYgnpTo lEO8nmQ8HqQzhc0lxEc7MCZ3P68A+GQ5zqicTl9spNgEr6Al46udiKvIqUvsAtH9e43O oeoOCLtmEkDAk4KXwZ1N9+763tak3wK/AQvSUJmyLbSU82qodO6RJgSOqF6jqtvJjEcD s4zg== 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=Z6a1wGdG7l77L3AQN5VjA/Lobs6OuBFqWivd/c5aWYE=; b=fXb8+DiwCIzK1jH5ZTdBhXR2BRjoBplbhyozB+tbO3j68F6NrlNSgZJqiuWXbEoKwK aXLjFbJo+ExZypMaA3WCEaq+hQ8dcOi6ZT3XSWrpEr5hKcTRtVdbZGGV2i+cpctwkoFp jeaDtbVis+tHw+Zst+Tebs52C1j1dhXGMd2csq/EmF87H9TSOx86LxuUJ8HGu925VLyT EMwe+MD4VOLyXqjH06n9t+90uGzFU9mwwt2MofNcZ/zCjydiWJIhwDTvYEVcsKlYaFgn lhe6ddMZZXZ07hsoVDnO1YZEY1f5Rv30XauINzXw/7gv55/m9MXmPQKAKTjqr2bwRlU7 ju6w== X-Gm-Message-State: AOAM530i7swZodr3RYBYm17WNKxz6wNepBLKc8s+V4NJuHD6nfW5xZZL +paBymzw6GPdnMD9r2PCvV9lcaagoLVThk+YjRg= X-Google-Smtp-Source: ABdhPJwzsaSbkTILFrtzSV8I9HSzs5TgSywpK63dV/sU8NQStLIRyFqtKpiKCuW7vYtz/K4wQkGmjkbXfQ2QcwhQ7gI= X-Received: by 2002:a05:6e02:1b87:: with SMTP id h7mr4083804ili.271.1622819142565; Fri, 04 Jun 2021 08:05:42 -0700 (PDT) MIME-Version: 1.0 References: <20210602203531.2288645-1-thomas@monjalon.net> <7088348.icZg66Z9Yi@thomas> <10019605.gdN4zKLbKd@thomas> In-Reply-To: <10019605.gdN4zKLbKd@thomas> From: Jerin Jacob Date: Fri, 4 Jun 2021 20:35:25 +0530 Message-ID: To: Thomas Monjalon Cc: dpdk-dev , Elena Agostini , Ferruh Yigit 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 Fri, Jun 4, 2021 at 6:25 PM Thomas Monjalon wrote: > > 03/06/2021 13:38, Jerin Jacob: > > On Thu, Jun 3, 2021 at 4:00 PM Thomas Monjalon wrote: > > > 03/06/2021 12:04, Jerin Jacob: > > > > On Thu, Jun 3, 2021 at 3:06 PM Thomas Monjalon wrote: > > > > > 03/06/2021 11:20, Jerin Jacob: > > > > > > The device needs have a queue kind of structure > > > > > > and it is mapping to core to have a notion of configure. queue_setup, > > > > > > start and stop etc > > > > > > > > > > Why is it a requirement to call it a device API? > > > > > > > > Then we need to define what needs to call as device library vs library and how? > > > > Why mempool is not called a device library vs library? > > > > > > My view is simple: > > > if it has drivers, it is a device API, except bus and mempool libs. > > > > rte_secuity has drivers but it is not called a device library. > > rte_security is a monster beast :) > Yes it has rte_security_ops implemented in net and crypto drivers, > but it is an API extension only, there is no driver dedicated to security. > > > > About mempool, it started as a standard lib and got extended for HW support. > > > > Yes. We did not change to device library as it was fundamentally > > different than another DPDK deices > > when we added the device support. > > > > > > and why all > > > > other device library has a common structure like queues and > > > > it binding core etc. I tried to explain above the similar attributes > > > > for dpdk device libraries[1] which I think, it a requirement so > > > > that the end user will have familiarity with device libraries rather > > > > than each one has separate General guidelines and principles. > > > > > > > > I think, it is more TB discussion topic and decides on this because I > > > > don't see in technical issue in calling it a library. > > > > > > The naming is just a choice. > > > > Not sure. > > > > > Yesterday morning it was called lib/gpu/ > > > and in the evening it was renamed lib/gpudev/ > > > so no technical issue :) > > > > > > But the design of the API with queues or other paradigm > > > is something I would like to discuss here. > > > > Yeah, That is important. IMO, That defines what needs to be a device library. > > > > > Note: there was no intent to publish GPU processing control > > > in DPDK 21.08. We want to focus on GPU memory in 21.08, > > > but I understand it is a key decision in the big picture. > > > > if the scope is only memory allocation, IMO, it is better to make a library. > > No it is only the first step. > > > > What would be your need and would you design such API? > > > > For me, there is no need for gpu library(as of now). May GPU consumers > > can define what they need to control using the library. > > We need to integrate GPU processing workload in the DPDK workflow > as a generic API. > There could be 2 modes: > - queue of tasks > - tasks in an infinite loop > In both modes, we could get completion notifications > with an interrupt/callback or by polling a shared memory. OK. If we have enqeue/dequeue kind operation and with queue model then it makes sense to have a device model. It was not there in your initial patch, but if we are adding in the future then it OK. > > >