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 07F9DA0C53; Wed, 1 Sep 2021 08:25:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C7B324013F; Wed, 1 Sep 2021 08:25:57 +0200 (CEST) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) by mails.dpdk.org (Postfix) with ESMTP id 03BFE40041 for ; Wed, 1 Sep 2021 08:25:57 +0200 (CEST) Received: by mail-io1-f51.google.com with SMTP id q3so2666293iot.3 for ; Tue, 31 Aug 2021 23:25:56 -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=BOMkvmTrcBdGgsrVF+n/szb7PsiUIGAsMKKteHE39pY=; b=D4eiEiVUn2peQ7pBSqmVBHkgC8JHBCi8oRAbMTJRZQrCBDVXKApLFPjLBT7TgIHtQB b7CrDHr0NNo+l+MeY2xvZOBw6Q9Zu3XapY5gqmGm67d0g8kA/TB6GPYpIiTwW+y2hDwZ ziDzQDw46FNBvV/VnktTYnTZ8Sy61/YrceioebfbQdfdOlKglHik03F36zVZ9jp/iocN tBvrw3318biPP4PP9zrEBwHl8F6bAcYol44uOYFGuY/I3j9p0JS/FD9DR/WjPoYE4vp8 adTVVduMQqe0U925RY5HVQXYX8v1NEQsMaytxpBmEDK+PUtxkNNEEDc8mINRn1+WBfu5 mGYA== 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=BOMkvmTrcBdGgsrVF+n/szb7PsiUIGAsMKKteHE39pY=; b=IagIvI5cUHDNZ8uZ2cEtieIb0QOAVCgkFV1g34YyMSeaH858wX+sF/BkPpxO6zeLW1 PWxd1WLu9GbfYEQQGxlBKQNE6FzY64Ihf5/Hiw1YlP/oJMu7FyBDuNEsBioFbsm0W6pq Bo5zzkWUtPRZyFFeUyWEWonN0skj9uFdD23aPWDR9H3gPghpGQHeyG5BHA2vl4YlB16B ieM2aJFEvZB13J4TE6ELpZP+kOWGuAwYm+e3/jLK4y9h2Maa+bmsq2pyOTBgRDaiFOy6 MglwRecFe2kvqxBayjNUOnV59WpvkXfl3yCM/MpcHoOMMX8Rg//hGaSei5IkRKu7Z9z8 lCvg== X-Gm-Message-State: AOAM531AIFTdT/awyPZBoe9evQl0v+jv7+7FWwl6N8HJcZjf5TTrtGie UObeiq6YKgZqsiuoPRZ23WeyVeKRmXGpuFc8rUw= X-Google-Smtp-Source: ABdhPJwb6F+RJ988pUcX4Rgmlr5pg+7pMer5HmxFVyT6dyZMoZvygIkuErsJn33i1nZ9jZmoz3SekeLUt3flX1t3Htc= X-Received: by 2002:a6b:fb0b:: with SMTP id h11mr25258501iog.59.1630477556248; Tue, 31 Aug 2021 23:25:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jerin Jacob Date: Wed, 1 Sep 2021 11:55:30 +0530 Message-ID: To: "Kaladi, Ashok K" , Harman Kalra , Nithin Dabilpuram , Ferruh Yigit , Anatoly Burakov , "Richardson, Bruce" , "Ananyev, Konstantin" , Thomas Monjalon , David Marchand Cc: "jerinj@marvell.com" , "Jayatheerthan, Jay" , "Carrillo, Erik G" , "Gujjar, Abhinandan S" , "dev@dpdk.org" , "Ayyadurai, Balasankar" Content-Type: text/plain; charset="UTF-8" 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 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 2) I think, This FIFO library should be generic and KNI also be a consumer of this library 3) I think, FIFO should not be a device instead it should be an abstact object like rte_mempool * 4) We need to consider User space app can be another DPDK primary process or some non DPDK app 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? 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. > > This RFC introduces control packet event adapter (CP adapter) and FIFO library > which can be used by user space applications to access the packets > handled by eventdev based DPDK application. Linux shared memory is used to > keep mempool (mbufs), packets and FIFOs. This allows copy-free access of > packets to both the applications. The Rx and Tx FIFOs are used to exchange > packets between the applications. > > '------------------' > | mempool | > '-------------' '-----------' |..................| '----------' '-----------' > | | | | | <--- Tx FIFOs | | | | | > | User space | | | | <--- Alloc FIFO | | Control | | DPDK | > | App <----> FIFO Lib <----> ---> Rx FIFOs <----> Packet <----> Eventdev | > | | | | | ---> Free FIFO | | Adapter | | App | > | | | | | | | | | | > '-------------' '-----------' | | '----------' '-----------' > '------------------' > > CP adapter does the mbuf allocation and free for user space application. Mbufs > allocated for user space application are put into alloc queue by CP adapter. > The used mbufs are put into free queue by user space application. > The FIFO lib translates packets between rte_mbuf format and a simplified > format which will be used by the user application. FIFO lib doesn't use any other > DPDK features than rte_mbuf structure. The simplified packet format contains only > essential parameters like address of the payload, packet length, etc. > > - user space app send path: When user space application wants to send > a packet, it takes an mbufs from Alloc FIFO, writes packet to it and puts it > into Rx queue. CP adapter which polls this queue gets the packet and enqueues > to eventdev. Then the mbuf is freed by CP adapter. > > - use space app receive path: CP adapter puts the packets to Tx FIFO, > user space application polls the FIFO and gets the packet. After consuming > the packet it puts the mbuf to be freed to free FIFO. CP adapter regularly > reads the free FIFO and frees the mbufs in it. > > The CP adapter can service multiple devices and queues. Each queue is > configured with a servicing weight to control the relative frequency with which > the adapter polls the queue, and the event fields to use when constructing > packet events. > > API Summary > > FIFO APIs: > - FIFO device open/close. > - API to allocate PDU buffer from alloc queue. > - API to send a burst of packets to an Rx FIFO identified by FIFO id and device id. > - API to receive a burst of packets from Tx FIFO identified by FIFO id and device id. > - API to put the used buffer to Free queue. Use application will call this after > using the payload. > > Control Packet Adapter APIs: > - Initialization API. > - Device addition and removal APIs > - Device configuration APIs. > - FIFO add and remove APIs. > - Event enqueue and dequeue APIs. > > > We look forward for your feedback on this proposal. Once we have initial feedback, > patches will be submitted for review. > > > Thanks & Regards > Ashok Kaladi >