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 20E38A034F; Mon, 11 Oct 2021 10:43:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D341F410E8; Mon, 11 Oct 2021 10:43:51 +0200 (CEST) Received: from mail-il1-f170.google.com (mail-il1-f170.google.com [209.85.166.170]) by mails.dpdk.org (Postfix) with ESMTP id 78724410DC; Mon, 11 Oct 2021 10:43:50 +0200 (CEST) Received: by mail-il1-f170.google.com with SMTP id k13so17296162ilo.7; Mon, 11 Oct 2021 01:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C7S2Qu6NOxThLWj/isZm/7kj0AxfHoBu6qk2yMWjPyc=; b=Z7Wcep7LMQaOVuc1OY0ZP9Gs9Fm9RPW5TeY0zDkZW5xR35xcCMMviURRojYGlvCE5R owl7oEkI79fr3CaRUe5O9ET4RYHSPrePqBfZIqzDCEMNsKvt5fzuz7GgxkDsIDxtS7t+ stL5nsgQdUXXSvnQtotZza8HdUOzqYgoFP2pKygVdFS1qk3VpPN3tzLpyOL2Oxvks9t+ ejedI6VrF0zrZTvwV5Qrug7R8vIzp9VKlT+0mmTQEAQ2W9yeEdCW69eE+YjljXda4rj9 4N84fM2vozQNRo3lMUllW7OtKaP89B8bEwibct9M+Oj6LZ/QHyYTBiP6M730uU6eUuBh xjGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C7S2Qu6NOxThLWj/isZm/7kj0AxfHoBu6qk2yMWjPyc=; b=tTKwL4GRIGfDeTnD6K5UqTKQXG6ScHknW74emOvQsqWIDD10r22pJHXWS2FFuhqv/L dOeGP/6AgsiA8tHRznoVVg6YLHcK1wPrvzFUIQh6zwWI/CLtM6/TgRUGhp5oiTH9WLvv U9e/AiXj2g+ph7ZmT/hnDYN3Y99m+7BEdF2M4cCkoVPcxIDn+6wcSq+GaaOUN6tX9R0l hQGHUOnfdI6ViUz7z1hSJjdMJQmxI2+qpgTUn45HJIn7CQbH9sgyNVZl2Pai1rFYObDw vU3H7zZgbySaDhSP8HYu8ZRmLCyTsVLTDdTXa/fW7LnEGBu1Br/CkIFSgwPOOmBQf5IC TaLw== X-Gm-Message-State: AOAM531UMHqhiAjNQHmiMKeZgdk/qZvp7AvzcfqUtwy2YJEncVTuexSo D8QPR//jKokSlvUc6NOGftJCJZLSptmgOULA3tE= X-Google-Smtp-Source: ABdhPJwwxmznow3gdLH7Cg9l4RLmyk/sJtiYtVqf8iA53GADRvVFad8Gcauo9fawO7WIzySgGPRbbVaQEWu1hXq+CAo= X-Received: by 2002:a05:6e02:1d8d:: with SMTP id h13mr7193205ila.94.1633941829854; Mon, 11 Oct 2021 01:43:49 -0700 (PDT) MIME-Version: 1.0 References: <20210602203531.2288645-1-thomas@monjalon.net> <20211009015349.9694-1-eagostini@nvidia.com> <2086339.rAQZMriH8I@thomas> In-Reply-To: <2086339.rAQZMriH8I@thomas> From: Jerin Jacob Date: Mon, 11 Oct 2021 14:13:24 +0530 Message-ID: To: Thomas Monjalon Cc: Elena Agostini , Ferruh Yigit , Honnappa Nagarahalli , dpdk-dev , techboard@dpdk.org Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3 0/9] GPU 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 Mon, Oct 11, 2021 at 1:48 PM Thomas Monjalon wrote: > > 10/10/2021 12:16, Jerin Jacob: > > On Fri, Oct 8, 2021 at 11:13 PM wrote: > > > > > > From: eagostini > > > > > > In heterogeneous computing system, processing is not only in the CPU. > > > Some tasks can be delegated to devices working in parallel. > > > > > > The goal of this new library is to enhance the collaboration between > > > DPDK, that's primarily a CPU framework, and GPU devices. > > > > > > When mixing network activity with task processing on a non-CPU device, > > > there may be the need to put in communication the CPU with the device > > > in order to manage the memory, synchronize operations, exchange info, etc.. > > > > > > This library provides a number of new features: > > > - Interoperability with GPU-specific library with generic handlers > > > - Possibility to allocate and free memory on the GPU > > > - Possibility to allocate and free memory on the CPU but visible from the GPU > > > - Communication functions to enhance the dialog between the CPU and the GPU > > > > In the RFC thread, There was one outstanding non technical issues on this, > > > > i.e > > The above features are driver specific details. Does the DPDK > > _application_ need to be aware of this? > > I don't see these features as driver-specific. That is the disconnect. I see this as more driver-specific details which are not required to implement an "application" facing API. For example, If we need to implement application facing" subsystems like bbdev, If we make all this driver interface, you can still implement the bbdev API as a driver without exposing HW specific details like how devices communicate to CPU, how memory is allocated etc to "application". > > > aka DPDK device class has a fixed personality and it has API to deal > > with abstracting specific application specific > > end user functionality like ethdev, cryptodev, eventdev irrespective > > of underlying bus/device properties. > > The goal of the lib is to allow anyone to invent any feature > which is not already available in DPDK. > > > Even similar semantics are required for DPU(Smart NIC) > > communitication. I am planning to > > send RFC in coming days to address the issue without the application > > knowing the Bus/HW/Driver details. > > gpudev is not exposing bus/hw/driver details. > I don't understand what you mean. See above. > > > Irrespective of the RFC I am planning to send and since the new > > library needs techboard approval, You may > > request that the techboard decide approval for this library. Also, As > > far as I remember a minimum a SW driver in > > additional to HW driver to accept a new driver class. > > No, only one driver is required: That is good news. > "When introducing a new device API, at least one driver should implement it." > Anyway, a SW driver doesn't make sense for gpudev. OK > > >