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 8A90BA0547; Sat, 31 Jul 2021 15:42:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0AD644014D; Sat, 31 Jul 2021 15:42:59 +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 6896740042; Sat, 31 Jul 2021 15:42:57 +0200 (CEST) Received: by mail-il1-f170.google.com with SMTP id f8so8991983ilr.4; Sat, 31 Jul 2021 06:42:57 -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=jUMcNJk4bBWR56Gl1hjewbF9kwlisyDcdzwqIbbFkf0=; b=JkpNveM8O1ofwvXa/eCbtmqtTe+DLmMk+QpGQOzhvdPlIH+FGBjmlU1+BwRkoYfTFT +ELZZPzDZuIFKmrtYQjcWi0QQLfng8HZv9YOOC/xVXwyjfn3pr8Ri3eyk1rB0HlBCJYh Cuk9e0oT4MjItQWnS9OuHv3+cztrPTN6GgFshF+avLvO2QqXaZe6ePRKJkhz8xIf37xu QSUQgHOU+s9Gaa9dJKn9Bc3GYHUU/n1F6cYv1Wh7Pi1NGlFLsJRReKq7qbOx0DPlkviu P8UBgnWw53rHrL8kg98LNXMTFZyzMVb+VhtL28BstrE1fHxqwLR/cGBKNhXxoDat6kmN kBlQ== 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=jUMcNJk4bBWR56Gl1hjewbF9kwlisyDcdzwqIbbFkf0=; b=IPZHvzV/B/yeJD1RtjD1Wf7P7xXIyHgU5qjlJTF415WQmkD9qRYmwMW7J7po1XfLV4 /KeogeOkwXBYKJCMNdrLVjuEEGg5YLS+3sYlRjCKyvj/stFnd6cnMxZRnyzmLdT/jKlB QSYz8Y598w+PxPRPbM7BOYhC6tX5orq/rHfkkg7SfCXPCcdwDU7GkLok6VPoB7oYz8Oo DQUuftlvZaXYVah2feLGyYakpXufAxtSl1+f8KASOtEmKWF5pPUbToNnTk03y/jyJLz9 Z4LHrI6CGkIyiQGH6XWTeunYno4idloORt6kZd0Ar+a49aMcauv4Lk1DdQYP2krLn8/V SL3Q== X-Gm-Message-State: AOAM532nxrOawDPjFEGBPO+K/XDiU58AOnXQVVk+hF9x7M4uBtljAwvk eiBlcNCy3RhkkqdTGanMTGFfFfjwf/MRVkrrsW0= X-Google-Smtp-Source: ABdhPJypR07bbd9s1OlumpyJ0nQ3KAKY82Pum6pE2szszWwpIqHzfGb2RzpJm55/Sn90NiJqCe3IdbM4I9+vUu/t3nQ= X-Received: by 2002:a05:6e02:b4b:: with SMTP id f11mr4633458ilu.130.1627738976450; Sat, 31 Jul 2021 06:42:56 -0700 (PDT) MIME-Version: 1.0 References: <20210602203531.2288645-1-thomas@monjalon.net> <20210730135533.417611-1-thomas@monjalon.net> <2204873.CS8KgQhqXy@thomas> In-Reply-To: <2204873.CS8KgQhqXy@thomas> From: Jerin Jacob Date: Sat, 31 Jul 2021 19:12:30 +0530 Message-ID: To: Thomas Monjalon Cc: dpdk-dev , Stephen Hemminger , David Marchand , Andrew Rybchenko , Haiyue Wang , Honnappa Nagarahalli , Jerin Jacob , Ferruh Yigit , techboard@dpdk.org Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing 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 Sat, Jul 31, 2021 at 1:51 PM Thomas Monjalon wrote: > > 31/07/2021 09:06, Jerin Jacob: > > On Fri, Jul 30, 2021 at 7:25 PM Thomas Monjalon wrote: > > > > > > From: Elena Agostini > > > > > > 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 other type of devices like GPUs. > > > > > > 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 device specific library with generic handlers > > > - Possibility to allocate and free memory on the device > > > - Possibility to allocate and free memory on the CPU but visible from the device > > > - Communication functions to enhance the dialog between the CPU and the device > > > > > > The infrastructure is prepared to welcome drivers in drivers/hc/ > > > as the upcoming NVIDIA one, implementing the hcdev API. > > > > > > Some parts are not complete: > > > - locks > > > - memory allocation table > > > - memory freeing > > > - guide documentation > > > - integration in devtools/check-doc-vs-code.sh > > > - unit tests > > > - integration in testpmd to enable Rx/Tx to/from GPU memory. > > > > Since the above line is the crux of the following text, I will start > > from this point. > > > > + Techboard > > > > I can give my honest feedback on this. > > > > I can map similar stuff in Marvell HW, where we do machine learning > > as compute offload > > on a different class of CPU. > > > > In terms of RFC patch features > > > > 1) memory API - Use cases are aligned > > 2) communication flag and communication list > > Our structure is completely different and we are using HW ring kind of > > interface to post the job to compute interface and > > the job completion result happens through the event device. > > Kind of similar to the DMA API that has been discussed on the mailing list. > > Interesting. It is hard to generalize the communication mechanism. Is other GPU vendors have a similar communication mechanism? AMD, Intel ?? > > > Now the bigger question is why need to Tx and then Rx something to > > compute the device > > Isn't ot offload something? If so, why not add the those offload in > > respective subsystem > > to improve the subsystem(ethdev, cryptiodev etc) features set to adapt > > new features or > > introduce new subsystem (like ML, Inline Baseband processing) so that > > it will be an opportunity to > > implement the same in HW or compute device. For example, if we take > > this path, ML offloading will > > be application code like testpmd, which deals with "specific" device > > commands(aka glorified rawdev) > > to deal with specific computing device offload "COMMANDS" > > (The commands will be specific to offload device, the same code wont > > run on other compute device) > > Having specific features API is convenient for compatibility > between devices, yes, for the set of defined features. > Our approach is to start with a flexible API that the application > can use to implement any processing because with GPU programming, > there is no restriction on what can be achieved. > This approach does not contradict what you propose, > it does not prevent extending existing classes. It does prevent extending the existing classes as no one is going to extent it there is the path of not doing do. If an application can run only on a specific device, it is similar to a raw device, where the device definition is not defined. (i.e JOB metadata is not defined and it is specific to the device). > > > Just my _personal_ preference is to have specific subsystems to > > improve the DPDK instead of raw device kind of > > path. If we decide another path as a community it is _fine_ too(as a > > _project manager_ point of view it will be an easy path to dump SDK > > stuff to DPDK without introducing the pain of the subsystem nor > > improving the DPDK). > > Adding a new class API is also improving DPDK. But the class is similar as raw dev class. The reason I say, Job submission and response is can be abstracted as queue/dequeue APIs. Taks/Job metadata is specific to compute devices (and it can not be generalized). If we generalize it makes sense to have a new class that does "specific function". > >