From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0072.outbound.protection.outlook.com [104.47.38.72]) by dpdk.org (Postfix) with ESMTP id 2AB5C2952 for ; Thu, 11 May 2017 18:39:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Rypv5YEN6HbAu+gjLwYzdiyfK31mDtNDGwraSkMFaYI=; b=Px/nVTWlCj9ozZyOEe0b/S1VLlNSojY+TeaR+h5P65BLFFOjyGgC7xG/3+5PIhbagUjoHDHg/3wf/FrllGi+DnsISyzaWcuhTplT7pAXX2akMeMtc4YWw/Bop5NAjJ52TrWUBksh6wMbuh5iyWJPGmqDuHPJkfCMYiJFplOsWmw= Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=caviumnetworks.com; Received: from jerin (122.167.66.53) by BLUPR0701MB1715.namprd07.prod.outlook.com (10.163.85.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Thu, 11 May 2017 16:38:57 +0000 Date: Thu, 11 May 2017 22:08:42 +0530 From: Jerin Jacob To: Gage Eads Cc: dev@dpdk.org, nikhil.rao@intel.com, thomas@monjalon.net, bruce.richardson@intel.com, harry.van.haaren@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com, narender.vangati@intel.com Message-ID: <20170511163840.GA18505@jerin> References: <1494362326-19832-1-git-send-email-gage.eads@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1494362326-19832-1-git-send-email-gage.eads@intel.com> User-Agent: Mutt/1.8.2 (2017-04-18) X-Originating-IP: [122.167.66.53] X-ClientProxiedBy: BMXPR01CA0011.INDPRD01.PROD.OUTLOOK.COM (10.174.214.149) To BLUPR0701MB1715.namprd07.prod.outlook.com (10.163.85.141) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9b63cf08-a1af-40ae-d8b0-08d4988c3a4c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:BLUPR0701MB1715; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1715; 3:ddL75xE8mLyO2DBbBDowIFlmW0+6tPf05tRsFuZ+JoQe+KEe1KDvstPbTdvTrCoqVNN6Vi4NYQiNDOrCVmw72uxQFCpcmGzHQu++O1m8AEb7mreR6unilHacdzahSL1uM5yZmt7kNMyebTpNe2bb0WYMr9KD63+IWWnL2IdaHRFXG6yWRMqroEsGfSaEWzKoqHUB2N9lVyZ/RWkRpoJfB7boYIRQTbcBH0yJQkU1uCWvDSUNLMwLRyQ245XnJNzi2ZlPFkhrG36T51F3Rqbo72eANrTU1ZhCjpR2amz1ExDan3ujy+x8wCScCBMOlXHs7W1am7Ee7aLdhJuGr6Iidw==; 25:dsLPmc7HvqdMUJk0CW6IkK0UTv+KICU5ue0aw/XpTYCm7rWIVLbpjS/HEHv6bXviZ8G3ANq+pwfQ+rZ2Yiai8x6kWUYnFtUxzAr1b3d9qSMbKngF8AE9aXZLoiMJYrfgsY7p7BmziZCqoQ/jJjs5ozdmyzXQQyHgei7Lj0bVtZ3MT297XSk/8NkZQh8L7JmQC8WZFR9cg9T4YW3F0kLXdqC9H0aENBY/df4w5PS9+RWvBOiC2LiZiMPi5QDFnBVsUNS40y+GFXcTH4QDeclRMQ6RXvneyTAlql48qWJQspYbKcffx/E6qaMzRpHgbirsX3QbA1z5JDlZx4yYSA5/t0cWkFFvXUategrxfPTul+SxI+KzxndlCUJ3WncT20EFgGBTMmHOTEw/ElqX8MCqfoHdi+IdX2qSpxTOzpcyBhiXpyt1C8ujBUb0Z8F1SQmSeSyTrnxvJzvWZHj0hn+/e3su1GxyRnIrY0JCa5gQzac= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1715; 31:F/y+zybck/k67SknUZzIUilKRCdDazjs1dOG5JDDf0qTm4SLikjOfSknT7j556BljxpxwB8z82ir/jhe4ZE/g/v3mzM2CpuHaFFblHQenQ2tsQOnUos9LWnKFho39OI8/0/ufQZA3yIz6fmr2fqaVdxTZ6nHuhELid/8+0J83Efh41jkaF3q6iCn5Kx0ClqbDXEk0Xai9ECShIc9qMkFNaDbJDhTPBbf9FL7Vge3i32yVdr6fz4IxwrlFkoqhY+G8WaXFZOAFQ0py1P/Q4w/qg==; 20:mlVqQTHsqqxxqOH2vg6WooCPyAZoK8UT9sivHFUxi1mBUqXrisBrdOxDwRG4GRg0JNStsp+7y4UoYSsiMDzWDlr3v4NW5XYdMDb5QLLIw7GYLSoeQzMzHEWcW6vy7XNPzxE6q+Y3q3WTVdrNfvK14wjLrKfH8T4pv8wu/Xjt7aglE5W9u9Tv2MaJ/XFdAfYAp+uogq4T2UeyN728DL2ZrXUV6U3yATGAgyYH4wIV8+C2a+chgCkxLx8EdeZIFqZQQS15ONCRw8ZjyVSI6T3i9gsyxkGIzIVSmDt4+jJOX953dfr8+JatEyfXYMwxGMcY3OMtMcLlKIhoy/Dw/f5XdnnGIZ58RpvQpSSRcqcJtlMF+Q+VosqCLi7tEojttsWAfhocba1RR3m/nKEaRHBtBMLbMO0L5DJ4xIi4MkkO8i45FDMETYhSrHGw7fiKYx91IyW2G7zm2XZeP+OADXJ74/P9Ir6elm0AFYGWUHvTHmDm5m7Cx5c9Rx8CxEGeKwROwM5slbuliyi8A1ZmD5pmpEv5/8GjiDxCTnIq7dwnl3Y68H5exMHNe1XwgVbBA2vRwCcrClrEegJiu13dBTw+lXbLHCsVdDez5HgGkXLguvo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(131327999870524)(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:BLUPR0701MB1715; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0701MB1715; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1715; 4:GM0NHDKN0RhAVCc0EEcnUJSSfskjrXj9F4KokJFZiknG/2hu8tR3j/38yGP9u+qGI6Rlxr9WsNibGqGQxdXMc8CZYx943xXkshfjZ/QN5E6cgEijHnp6fRi7VJryu4XdRelJmhUhfDL5CVzICjdyVDaA/TeTTDaFqUwNHfIs1XZ/w1Z0GMOwkL4ocKNdJ6QXLElw9zFpG6aXTzCA7HyZ1tDVTyv1nCw5yL5XH3x2Ce6eAu+pEp6Il4Q9sG4KboMt+m4fGichXDr5GRHv9W6yq4Qe5y2Jts0pKRDIzSjj7NYgFwobfHh4hcreH8h92NWsqyIbDHC7GC45K1nnjoybz6x58zJsM9vexZVtD6fxfJErZdQK3X+bOuNYzF4kwTicU2VZGAA9Lbq+3Ezq4hVEi3PAD9Vcsrcb0eeBeoPfG6zoQm2x6C4zKgGwPv5YiYy98We9B/Z/sfmsM6a0gUL0tTnDm6TYFrYOihcas9gB+1cBoGQmURtGm423eDni3nnleta3GZMVmrRCBLUMU7cbfP0pz1yVTDWOwhOXc9O0iK9cxo/gNIcmAx3YL+TC11hIgfPOky23Y9BvVQwDQtZ8ijzLqBOQvqg7NGgsUKPnOjdSGXYNgMclUNSQmKCOSUILW39yEI3aziO5MqiQVqvEQJ0TMaOI45bjjUNXA7NMUEC6zAiaO445N18R4BMe2aH+bH0K7gmkz+bbRm8MHVHgEmn3bQU+IfoUzma/un8j7+3rumdHOXUUk9QSgCsPgON06VM0bk98pvsUynh7mld2i/urgPa76wIV2g6oWEJwSBgTEFr5jzJspmoHjLemR9vlzEE1WixMPGDguBNT4emI28H1PdFo6R6pBaDA8fF+fGo9hXps/EzTaK8AjHH0GjreCkWHPxrQrwM1+HRPaTJrUucMA0MVHe5Af/moYvYaC+A= X-Forefront-PRVS: 0304E36CA3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(39450400003)(39400400002)(39840400002)(39850400002)(39410400002)(76104003)(51914003)(25584004)(13464003)(72206003)(47776003)(83506001)(2950100002)(66066001)(23726003)(6116002)(42186005)(3846002)(50466002)(25786009)(4326008)(2906002)(1076002)(305945005)(7736002)(42882006)(6916009)(5660300001)(966004)(6246003)(6666003)(229853002)(8656002)(4001350100001)(189998001)(8676002)(81166006)(76176999)(50986999)(561944003)(478600001)(6306002)(6496005)(55016002)(33656002)(53936002)(110136004)(54356999)(33716001)(38730400002)(53376002)(9686003)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1715; H:jerin; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0701MB1715; 23:ZkB9OuKn7Z6F/tpTjR9PSsslGBQVFTs9T/H/0fP?= =?us-ascii?Q?4qd9PgOI6iB9rOyjoaaIMZl8Q8+j0AKSfs6gCcOWNX85dmiaCqf1C9xzq5U9?= =?us-ascii?Q?v7qReE2xpmRL7nLbclU+TS361I7YfqOCF8liT/eExRGXoIs7pExUstMeSxWF?= =?us-ascii?Q?wNbWBnFaWGJUvMqe39Ay6T4Vz3+X0xXLdM5tT1f9biPdYyjnJwwZ2UANHoUj?= =?us-ascii?Q?MMs1kNUZ7EebOVYmxchzn+jT3q85D2R/5oWwrTBBVWKlfPgl7pGpiOqbnK9x?= =?us-ascii?Q?zJjzEktgsFFm3V2MYKmo3jWawNtdhvf1IKb58qvm1R10N0iT81SYndvFKVUI?= =?us-ascii?Q?tj6brzUJWjWkjwvZuTx5dyPvo+BMKf4XfIaQmHaBWQNFafCBkw+XvD4/kgsk?= =?us-ascii?Q?q/r8Hctb/fFemN6gTY/whoUyNE0kQciHub+uay0HWi1zXJWcaDC/yXIghYTy?= =?us-ascii?Q?RqDF4rPJylywCO2Ej9msDJYv+XdGnB8ORodrvU3pSaLjEe0qdZe/mx4Zwq4Q?= =?us-ascii?Q?CxbzUComkXv/onmU3NyelKoa23QxNJMWgqc/BMQVBxssBr6F9RRGDTR2Xef9?= =?us-ascii?Q?fdcjb6RKV2qA4N+MuI9JGwNdw2ljOCYdcrZJLCtIxmspacavsHN5kXZuhzIg?= =?us-ascii?Q?BpAPaPPUr4xWyLxbYBZoLqCZ3Re+Ou11ckjaNJBrDvWbPnkcEqIFVa0lmWkv?= =?us-ascii?Q?OQ1Ur7LRmQwG4g42mZblZfw5uqLcVMWbsAuCIoydSxlZL0RVVf645pqpzgac?= =?us-ascii?Q?8Ssp/xK8hGKB67UNsciRvLkO9scK3rruxdDWTvudWRkQLdJBibbdPtK4N0Iz?= =?us-ascii?Q?YUDLKpoglJxCKFpqQD8VJO6yuVLtWTJN8KP8LVaIz31lTf0A3N+BSRqc6zqx?= =?us-ascii?Q?MLmn6YPI2xhLhQo+RMGpjWJ0oLhIdDV97XQFkjdPf6732eDb3kvRzxE+CfSx?= =?us-ascii?Q?DPG2RVijoj45ZjCI5xEpFyjlTdFzgjo/TQGJFEbi+YQ04tpzxzqS+d1MrQtk?= =?us-ascii?Q?OZ6EDpoyxfce5fdVuJVkuH7gu0z4bBdDaURWzrfgk3yaquMeM9STTMP8b00v?= =?us-ascii?Q?bWNos/ykd4zZw1oyr90JWL6tmtykjZ+2i6Ih8IPXo47vtdXxGqAEVunB/1n3?= =?us-ascii?Q?qhnf2Zc1CEq5/8L+olOMqNgrnO3VpSvV9Sr3eKiyIiv9G+vHkDywGq62sqIC?= =?us-ascii?Q?lUmDfA176HbBDCpgKKRL77uRWEb7qQn6D9qh7GOYsJKSsO14hhjY6J8fomh1?= =?us-ascii?Q?O+ANq5LKBzU56xUZvzR6y2twwUlv2EkJQ9aBkexntgVPgsDZ4Yz3c9LO4Wsq?= =?us-ascii?Q?NN4LCSmB1KuCIYDsZCXeln3D9Vn01z6HVxYzqmu7ePpeM?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1715; 6:qZcH/9zRSiNPdczWc641KKQf1rosWVRvSQEXvV0N/ELZfqbtqEOUTyCOQPQjobMTkTJvzymdO0c6j68xKeyRRm5d7kCNaQuSvnfR6T3zlZHAAtDnLXgFsaK4ICvVL2PtE2M/Wf6cy/fW/GYxJQzLT8lPZ/JmzpaztaRQnju6nmGSWu3IqIUAh0jSI92LnFxjxK4WWwDWSoaFQyLCw5G4qSpjMl6Z/DDx4L51zp5Zj3WiQl4VdR7vJu/fNpQXG9WSc4h5Imss6RrqO43xTTXDtfb4bcjJejZPN5/Lv9bSOpHf4HuMZdDDUxoGC3bTQCBVZwLAZ2Df/f3a8D2uuHBdh4TA0mLclsWgWgYSpr4Kv2XhPxeMUHOOAbGCvxSZWwfFXhp5CfK6C4E0QGFF9aNHnvWTHOLX70zmou3j9VOErHP9ol+MOqYIDL2GyqNBnKd/QGP8kCDJbtHUsPRV4EIHKPt5ecj6H5EJRTMs1SAtmnoHWWJdA4fyMxST0IGI7j8jV2hvFnCLR2YxYLzsXUTvVw==; 5:xakEfG01G+MZKsrbZ9u8Y2nKBsBlZDFEPMlsfJDVc+6hYToo+g/hnKCjKRl4iHNF0fhjV969EQg81ZyYqMyDHXosYi1WF9bWxebgoBskvkPzrEIzNdoSEjBUDdMZRsoqs2OEHaZwREbjTUUzmYHOSw==; 24:/+X+g/eYf/xVpML2fLxyl+RlWzxSMh2m39nmFDK9/ktWcwA1sbJPOeqcRfWpW9MTBXTx/OoqgI8hzNO0rUCEqa2XGTqWqKhgtpJCZE7qqis= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1715; 7:TMNVEfRYxibr+xa7OPl7QhSovmUZQxjGeIsqWP95krhzAxhW9rWI/m1TNsHD66qcNguPrV8Iz9V/hXyqT+obCOUPOUx5EuZxI4qqQANd+BwZmxrgnIkM9kX8tbn6MucmngTVyG4cxjjMOzCRAqbDl+rlGzCrXKTee1ptnrf04upQsahbFX3ZxjlPlurHdBcfJi/oGUHrgTDEbqEWKVNEwtRNZCA9XBz6mUeMKvQIfxx/zD7XqIOOyoiFTi4inpEhGNWwrjR7bMK8v6DQPR4pC2w86mceCuzIV8zephzNHsxtehYUyb1OlxqRnpS4xt78n5CdS8PrmIKLMvdSbCNHyA== X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2017 16:38:57.4201 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1715 Subject: Re: [dpdk-dev] [RFC] eventdev: add event adapter for ethernet Rx queues X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 16:39:02 -0000 -----Original Message----- > Date: Tue, 9 May 2017 15:38:46 -0500 > From: Gage Eads > To: dev@dpdk.org > CC: nikhil.rao@intel.com, jerin.jacob@caviumnetworks.com, > thomas@monjalon.net, bruce.richardson@intel.com, > harry.van.haaren@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com, > narender.vangati@intel.com > Subject: [RFC] eventdev: add event adapter for ethernet Rx queues > X-Mailer: git-send-email 2.7.4 > > From: Nikhil Rao Hi Nikhil and Gage, Thanks for the RFC. A few questions and comments below. Looks like SW has more constraints on event producer side, after we finalize on this RFC(I guess only a few minor changes are only required). I will align other[1] RFC based on _your_ RFC as we need to converge on name space and we can't duplicate configs like struct rte_event_dev_producer_conf etc [1] http://dpdk.org/ml/archives/dev/2017-May/065341.html > > Eventdev-based networking applications require a component to dequeue > packets from NIC Rx queues and inject them into eventdev queues[1]. While > some platforms (e.g. Cavium Octeontx) do this operation in hardware, other > platforms use software. > > This RFC introduces an ethernet Rx event adapter and a proposed header > file. This adapter service dequeues packets from ethernet devices and > enqueues them to event devices. > > The adapter is designed to work with the EAL service core proposal[2]. If > an application determines that the adapter is required, it can register and > launch it on a service core. Alternatively, this adapter can serve as a > template for applications to design customer ethernet Rx event adapters > better suited to their needs. > > The adapter can service multiple ethernet 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. The adapter has two modes for programming an > event's flow ID: use a static per-queue user-specified value or use the RSS > hash. > > A detailed description of the adapter is contained in the header's > comments. > > [1] http://dpdk.org/ml/archives/dev/2017-May/065341.html > [2] http://dpdk.org/ml/archives/dev/2017-May/065207.html > > Signed-off-by: Nikhil Rao > Signed-off-by: Gage Eads > --- > + > +/** > + * @file > + * > + * RTE Ethernet Rx Adapter for Eventdev > + * > + * An eventdev-based packet processing application enqueues/dequeues mbufs > + * to/from the event device. The ethernet Rx event adapter's role is to transfer > + * mbufs from the ethernet receive queues managed by DPDK to an event device. > + * The application uses the adapter APIs to configure the packet flow between > + * the ethernet devices and event devices. The adapter is designed to work with > + * the EAL service cores. The adapter's work can be parallelized by dividing the > + * NIC Rx queues among multiple adapter services that run in parallel. > + * > + * Before using the adapter, the application needs to enumerate and configure > + * the ethernet devices that it wishes to use. This is typically done using the > + * following DPDK ethdev functions: > + * - rte_eth_dev_configure() > + * - rte_eth_tx_queue_setup() > + * - rte_eth_rx_queue_setup() > + * - rte_eth_dev_start() > + * > + * The application also configures an event device and creates event ports > + * to interface with the event device. In addition to the event ports used by > + * its packet processing functions, the application creates an event port > + * to be used by this adapter. > + * > + * The ethernet Rx event adapter's functions are: > + * - rte_eth_rx_event_adapter_create() > + * - rte_eth_rx_event_adapter_free() > + * - rte_eth_rx_event_adapter_dev_add() > + * - rte_eth_rx_event_adapter_dev_del() > + * - rte_eth_rx_event_adapter_queue_add() > + * - rte_eth_rx_event_adapter_run() > + * - rte_eth_rx_event_adapter_stats_get() > + * - rte_eth_rx_event_adapter_stats_reset() > + * > + * The applicaton creates an event to ethernet adapter using > + * rte_eth_rx_event_adapter_create(). The event device and event port > + * identifiers are passed to this function. Next, the application adds ethernet > + * devices to this adapter using rte_eth_rx_event_adapter_dev_add(). > + * > + * The adapter needs to know which ethernet rx queues to poll for mbufs as well > + * as event device parameters such as the event queue identifier, event > + * priority and scheduling type that the adapter should use when constructing > + * events. The rte_eth_rx_event_adapter_queue_add() function is provided for > + * this purpose. > + * > + * At the time of adding an ethernet device receive queue, the application can > + * also specify a static event flow id and set the > + * RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID bit of the rx_queue_flags > + * member of the rte_eth_rx_event_adapter_queue_config structure. If the > + * RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID isn't set, the flow id is > + * assigned the value of the RSS hash. The adapter generates the RSS hash if it > + * hasn't been already computed by the NIC, based on source and destination > + * IPv4/6 addresses, using the rte_softrss_be() routine included in the DPDK. > + * > + * The servicing weight parameter in the rte_eth_rx_event_adapter_queue_config > + * intended to provide application control of the polling frequency of ethernet > + * device receive queues, for example, the application may want to poll higher > + * priority queues with a higher frequency but at the same time not starve > + * lower priority queues completely. If this parameter is zero and the receive > + * interrupt is enabled when configuring the device, the receive queue is > + * interrupt driven; else, the queue is assigned a servicing weight of one. Looks good. > + */ > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > +#include > +#include > +#include > + > +/* struct rte_eth_rx_event_adapter_queue_config flags definitions */ > +#define RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID 0x1 > +/*< This flag indicates the flow identifier is valid */ > + > +struct rte_eth_rx_event_adapter_config { Since this code is going to be at lib/librte_eventdev, We must start all public symbols and file name with rte_event_*. example: May be this structure can be changed as rte_event_eth_rx_adapter_config > + uint8_t event_dev_id; > + /**< Event device identifier */ > + uint8_t rx_event_port_id; > + /**< Event port identifier, the adapter enqueues mbuf events to this > + * port > + */ > +}; > + > +struct rte_eth_rx_event_adapter_queue_config { > + uint32_t rx_queue_flags; > + /**< Flags for handling received packets */ Better to add references with @see example: @see RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID > + uint16_t servicing_weight; > + /**< Relative polling frequency of ethernet receive queue, if this > + * is set to zero, the Rx queue is interrupt driven > + */ > + struct rte_event ev; > + /**< > + * The values from the following event fields will be used when > + * enqueuing mbuf events: > + * - event_queue_id: Targeted event queue ID for received packets. > + * - event_priority: Event priority of packets from this Rx queue in > + * the event queue relative to other events. > + * - sched_type: Scheduling type for packets from this Rx queue. > + * - flow_id: If the RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID bit > + * is set in rx_queue_flags, this flow_id is used for all > + * packets received from this queue. Otherwise the flow ID > + * is set to the RSS hash. This scheme is good. I was duplicating the elements in "struct rte_event_dev_producer_conf" IMO, We need to set ev.event_type == RTE_EVENT_TYPE_ETHDEV implicitly in library. You can mention that here as a info. > + */ > +}; > + > +struct rte_eth_rx_event_adapter_run_args { > + uint8_t id; > + /**< Adapter identifier */ > + unsigned int max_nb_rx; > + /**< The adapter can return early if it has processed at least > + * max_nb_rx mbufs. This isn't treated as a requirement; batching may > + * cause the adapter to process more than max_nb_rx mbufs. > + */ > +}; > + > +struct rte_eth_rx_event_adapter_stats { > + uint64_t rx_poll_count; > + /**< Receive queue poll count across both polled and interrupt mode > + * queues > + */ > + uint64_t rx_packets; > + /**< Received packet count */ > + uint64_t rx_enq_fail; > + /**< Eventdev enqueue failed count */ > + uint64_t rx_enq_retry; > + /**< Eventdev enqueue retry count */ > +}; > + > +/** > + * Create a new ethernet Rx event adapter with the specified identifier. > + * > + * @param adapter_id > + * Event adapter identifier. > + * @param config > + * Event adapter config parameters. > + * @return > + * - 0: Success > + * - <0: Error code on failure > + */ > +int rte_eth_rx_event_adapter_create( > + uint8_t id, > + const struct rte_eth_rx_event_adapter_config *config); > + One adapter creates one service function. right? It is good to mention the mapping.It is missing in the doc. > +/** > + * Free an event adapter > + * > + * @param id > + * Adapter identifier. > + * @return > + * - 0: Success > + * - <0: Error code on failure > + */ > +int rte_eth_rx_event_adapter_free(uint8_t id); > + > +/** > + * Add eth device to the event adapter > + * > + * @param id > + * Adapter identifier. > + * @param eth_dev_id > + * Port identifier of the Ethernet device. > + * @return > + * - 0: Success > + * - <0: Error code on failure > + */ > +int rte_eth_rx_event_adapter_dev_add(uint8_t id, uint8_t eth_dev_id); rte_eth_event_rx_queue_add() also have eth_dev_id.What is the significance of eth_dev_id here. Looks like eth_dev_id is a duplicate info. if it is duplicate or it can be avoided then I propose to reduce the number of APIs for easiness of application programming(i.e removing rte_eth_rx_event_adapter_dev_add, rte_eth_rx_event_adapter_dev_del) You can also mention the following for better clarify. If following is true.If not, What do you think about, co-existence of poll and event mode? The rte_eth_rx_burst() result is undefined if application invokes on bounded ethdev_port and rx_queue_id. > + > +/** > + * Delete eth device from an event adapter > + * > + * @param id > + * Adapter identifier. > + * @param eth_dev_id > + * Port identifier of the Ethernet device. > + * @return > + * - 0: Success > + * - <0: Error code on failure > + */ > +int rte_eth_rx_event_adapter_dev_del(uint8_t id, uint8_t eth_dev_id); > + > +/** > + * Add receive queue to event adapter > + * > + * @param id > + * Adapter identifier. > + * @param eth_dev_id > + * Port identifier of Ethernet device. > + * @param rx_queue_id > + * Ethernet device receive queue index. > + * @param config > + * Additonal configuration structure. > + * @return > + * - 0: Success, Receive queue added correctly. > + * - <0: Error code on failure. > + */ > +int rte_eth_event_rx_queue_add( > + uint8_t id, > + uint8_t eth_dev_id, > + uint16_t rx_queue_id, How about changing it as int32_t rx_queue_id and -1 to denote all Rx queues configured for given eth_dev_id are added. This will avoid the case where application needs to call this API one by one when application interested in all the queues. > + const struct rte_eth_rx_event_adapter_queue_config *config); > + Don't we need rte_eth_event_rx_queue_del() for tear down?