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 873B9A0C56; Wed, 1 Sep 2021 21:45:48 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4705E40687; Wed, 1 Sep 2021 21:45:48 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 9D6CB40686 for ; Wed, 1 Sep 2021 21:45:46 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 298F840005 for ; Wed, 1 Sep 2021 21:45:46 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 0F0FE4000F; Wed, 1 Sep 2021 21:45:46 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A autolearn=disabled version=3.4.2 X-Spam-Score: -1.5 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 07EAB40005; Wed, 1 Sep 2021 21:45:43 +0200 (CEST) To: "Kaladi, Ashok K" , "jerinj@marvell.com" , "Jayatheerthan, Jay" , "Carrillo, Erik G" , "Gujjar, Abhinandan S" , "dev@dpdk.org" Cc: "Ayyadurai, Balasankar" References: From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: <10d64164-2f55-ea5c-af01-80ef9684d5f8@ericsson.com> Date: Wed, 1 Sep 2021 21:45:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2021-09-01 07:41, 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. > How about using memif and the eventdev RX adapter to solve this problem? > 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. > On a control-type interface zero-copy or not shouldn't really matter, and also seem likely to result in higher coupling and a more error-prone interface between the DPDK app and the other app. > '------------------' > | 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. > > One thing to consider is if this FIFO service should provide guaranteed and/or in-order delivery. That in turn probably depends on if you by "control" mean slow-path traffic (ARP etc), or more RPC/IPC type control signaling (e.g. an "add this route" or "retrieve these stats" message). > Thanks & Regards > Ashok Kaladi >