From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH] examples/l3fwd: adding event queue support Date: Thu, 12 Apr 2018 19:50:48 +0530 Message-ID: <20180412142047.GA18670@jerin> References: <20180319134520.28155-1-sunil.kori@nxp.com> <20180412140322.GA59668@bricha3-MOBL.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sunil Kumar Kori , "dev@dpdk.org" , Hemant Agrawal To: Bruce Richardson Return-path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0078.outbound.protection.outlook.com [104.47.37.78]) by dpdk.org (Postfix) with ESMTP id C68D01C0A5 for ; Thu, 12 Apr 2018 16:21:10 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20180412140322.GA59668@bricha3-MOBL.ger.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" -----Original Message----- > Date: Thu, 12 Apr 2018 15:03:22 +0100 > From: Bruce Richardson > To: Sunil Kumar Kori > CC: "dev@dpdk.org" , Hemant Agrawal > Subject: Re: [dpdk-dev] [PATCH] examples/l3fwd: adding event queue support > User-Agent: Mutt/1.9.4 (2018-02-28) > > On Thu, Apr 12, 2018 at 06:09:04AM +0000, Sunil Kumar Kori wrote: > > Gentle reminder to review the RFC. > > > > Regards > > Sunil Kumar > > > > Hi, > > sorry for the delay in review. > > /Bruce > > > -----Original Message----- > > From: Sunil Kumar Kori [mailto:sunil.kori@nxp.com] > > Sent: Monday, March 19, 2018 7:15 PM > > To: dev@dpdk.org > > Cc: Sunil Kumar Kori ; Hemant Agrawal > > Subject: [PATCH] examples/l3fwd: adding event queue support > > > > This patch set to add the support for eventdev based queue mode support to the l3fwd application. > > 1. Eventdev support with parallel queue > > 2. Eventdev support with atomic queue > > > > This patch adds > > - New command line parameter is added named as "dequeue-mode" which > > identifies dequeue method i.e. dequeue via eventdev or polling > > (default is polling) > > . If dequeue mode is via: > > a. eventdev: New parameters are added -e, -a, -l to cater > > eventdev config, adapter config and link configuration > > respectively. "--config" option will be invalid in this case. > > b. poll mode: It will work as of existing way and option for > > eventdev parameters(-e, -a, -l) will be invalid. > > > > - Functions are added in l3fwd_em.c and l3fwd_lpm.c for packet I/O > > operation > > > > The main purpose of this RFC is get comments on the approach. > > This is a *not tested* code. > > > > Signed-off-by: Sunil Kumar Kori > > --- > > examples/l3fwd/Makefile | 2 +- > > examples/l3fwd/l3fwd.h | 21 ++ > > examples/l3fwd/l3fwd_em.c | 100 ++++++++ > > examples/l3fwd/l3fwd_eventdev.c | 541 ++++++++++++++++++++++++++++++++++++++++ > > examples/l3fwd/l3fwd_eventdev.h | 85 +++++++ > > examples/l3fwd/l3fwd_lpm.c | 100 ++++++++ > > examples/l3fwd/main.c | 318 +++++++++++++++++++---- > > examples/l3fwd/meson.build | 2 +- > > 8 files changed, 1120 insertions(+), 49 deletions(-) create mode 100644 examples/l3fwd/l3fwd_eventdev.c create mode 100644 examples/l3fwd/l3fwd_eventdev.h > > > > My initial impression is that this seems like an awful lot of new code just > to support reading from an eventdev rather than from an ethdev. Looking at > the datapath main function loop, is the only difference there that > rte_eth_rx_burst has been changed to rte_eventdev_dequeue_burst or are > there more significant changes than that? > > If this is the case, is this scale of changes really needed to this app? > What about the other examples, how many of them will need to be similarly > updated? > > I'm also wondering if it would help, or be useful, to have a vdev type > which wraps an eventdev queue as an ethdev. That would eliminate the need > for the datapath code, and may help abstract away some parts of the setup. > It would also help with re-use if you anticipate wanting to make a similar > change to other apps. Exposing as an ethdev-vdev device will introduce cyclic build dependency(now eventdev is depended on ethdev). I think, maybe a helper function in eventdev area to setup Rx adapter and similar slow path logic may work. > > /Bruce >