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 2A771A0C4D; Thu, 2 Sep 2021 08:50:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 94F5C40041; Thu, 2 Sep 2021 08:50:42 +0200 (CEST) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) by mails.dpdk.org (Postfix) with ESMTP id 294004003C for ; Thu, 2 Sep 2021 08:50:41 +0200 (CEST) Received: by mail-io1-f44.google.com with SMTP id z1so1156340ioh.7 for ; Wed, 01 Sep 2021 23:50:41 -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:content-transfer-encoding; bh=GgYT3WUnPvvhqWW2a6B3c69gtVGAz40DkgtBTnSl+6w=; b=M6q4C4SuXtM5f0s6/hBrk3fUmdTG5kqoOHipVS4a5j4nClr1kpBLpWRPf3632MPW6f oV8V6ntd2wrn/rmX4ynyVeF9wlZ9Pu++UHRZfMzgnAawUbli0EkI4cEmLCCeRka8lTVb WcF3FQj1M4MNxXD2nY9vIxPVPjBBD7MqV/oiErEBDqUiR+gcfxzVa4k/iXHPjP5iox51 wLzMDhgLOs0Fdmkm/Iu05iGhxp+jMwUOajmrd7Kk8P5TDvyMuXltZJV4Xle0ArvBhHLl LSOKpjK+RVYr7uE0O/E0xAo1P/InIabN/sDltouiKE+fb7W5OJEn+nRXMvT5zctMYmZr IgLw== 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:content-transfer-encoding; bh=GgYT3WUnPvvhqWW2a6B3c69gtVGAz40DkgtBTnSl+6w=; b=enF6V/p6sY61Z7997GjaM1JNDpOicr8MVcH0CNhsqG7WdtBHNBm0/F+owxxFnfuOwa MA8wqqae9RczBFZFntdvLSQmKYH+cEO/tj8y0qOfTxtDjNyG2AFJopuUJKQY6hBISTai G64j1ffl6WsqDWArQP+fQYv1/HTSN08xqhR3h/LYPyODEkT4I0oXw8+2eDvHS5nj+IVZ NR13l8knTP1fS41fTVDqWwVlkdY+xkaEUKPvQUAXlE9OlUGq5yc7m1mYWCYTeewPQguQ iXws/QvMgRDAdyMK0DQ3Kv5dla1IYbMq2XUzk8FYDOgwzaaRt2FPphbFTa/kKC+Ri9Mn JS+A== X-Gm-Message-State: AOAM530YYx3psv0ig58U78+PCK/ouqeqq8a6zReHQzL3gZAZb5CAKINq 5tbPGcWsqHTiPK6OKTksENZ6FsxuMiHan9IapVI= X-Google-Smtp-Source: ABdhPJzM6kyeRvY9zO1II4S3Y0+c58sr7OisgVarN6jIZ8GsPM091hvHr5DFaOvwLEAgiLhzokmI9EgaCTOdA6UdQks= X-Received: by 2002:a05:6602:1543:: with SMTP id h3mr1540602iow.123.1630565440446; Wed, 01 Sep 2021 23:50:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jerin Jacob Date: Thu, 2 Sep 2021 12:20:14 +0530 Message-ID: To: "Kaladi, Ashok K" Cc: Harman Kalra , Nithin Dabilpuram , "Yigit, Ferruh" , "Burakov, Anatoly" , "Richardson, Bruce" , "Ananyev, Konstantin" , Thomas Monjalon , David Marchand , "jerinj@marvell.com" , "Jayatheerthan, Jay" , "Carrillo, Erik G" , "Gujjar, Abhinandan S" , "dev@dpdk.org" , "Ayyadurai, Balasankar" , Jakub Grajciar , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC] Control packet event adapter and FIFO 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, Sep 2, 2021 at 10:02 AM Kaladi, Ashok K wrote: > > Hi Jerin, Hi Ashok, > > > -----Original Message----- > From: Jerin Jacob > Sent: Wednesday, September 1, 2021 1:20 PM > To: Kaladi, Ashok K ; Harman Kalra ; Nithin Dabilpuram ; Yigit, Ferruh ; Burakov, Anatoly ; Richardso= n, Bruce ; Ananyev, Konstantin ; Thomas Monjalon ; David Marchand > Cc: jerinj@marvell.com; Jayatheerthan, Jay ;= Carrillo, Erik G ; Gujjar, Abhinandan S ; dev@dpdk.org; Ayyadurai, Balasankar > Subject: Re: [dpdk-dev] [RFC] Control packet event adapter and FIFO libra= ry > > On Wed, Sep 1, 2021 at 11:55 AM Jerin Jacob wrote= : > > > > On Wed, Sep 1, 2021 at 11:12 AM Kaladi, Ashok K > > wrote: > > > > > > Dear dpdk-dev team, > > > > > > We would like to propose the following RFC for your review. > > > > > > A user space application may need access to the packets handled by > > > eventdev based DPDK application. This application doesn't use mbuf > > > or eventdev based DPDK APIs. Presently this is not possible without > > > passing packets through DPDK KNI. > > > > > > I think it is an innovative idea it is useful for multiple use cases > > not just for eventdev. > > > > Some feedback on thoughts > > > > 1) The FIFO library should be generic it should not be specific to > > eventdev > > Agreed, it's planned to be generic. > > > 2) I think, This FIFO library should be generic and KNI also be a > > consumer of this library > > Agreed, any adaptation needed in KNI can be taken up later. > > > 3) I think, FIFO should not be a device instead it should be an > > abstact object like rte_mempool * > > FIFO is comparable to queue. We will have a data structure which contains= address of Rx, Tx, Alloc & Free FIFOs, number of queues etc. > This can be used to create a device. This method is similar to KNI - str= uct kni_dev. > > > 4) We need to consider User space app can be another DPDK primary > > process or some non DPDK app > > Agreed > > > 4) I think, we can remove the Linux shared memory dependency instead > > of introduce some scheme of "exporting" memzone from DPDK application > > to another user space app or another DPDK primary process. > > I see the following reasons: > > - It is backed by hugepage so better performance > > - Is kernel do any memcpy when using Linux shm calls in kernel space? > > We are proposing to use POSIX complaint APIs shm_open(), mmap() APIs to c= reate shared memory to avoid dependency on Linux. > The shared memory is created in Hugepages and contains mempool and mbufs.= This is done by control packet adapter. > This avoids application to be aware of these DPDK constructs. It just nee= ds to know about the simplified format defined by FIFO lib. > Proposed use case is for user space application which doesn=E2=80=99t nee= d memcpy as mempool is in shared memory. > For Kernel application we may use similar approach as in KNI. This can be= taken up later. + memif maintainer ( jgrajcia@cisco.com ) I just looked memif, based on a suggestion from @Mattias R=C3=B6nnblom Looks like memif is already solved this problem in a clean way and DPDK has support for the same as ethdev driver. I think, it has only a downside that it has Linux OS dependency due to memfd_create(). Any other downside for memif? I think, may be, we need to weigh in pros and cons of memif vs new proposing library. Could you check the same? > > > > > Thoughts? > > > > May be you can share set of API prototypes without any implementation > > for the next level discussion if others are OK this kind of library. > >