-----Original Message----- > Date: Tue, 12 Sep 2017 17:59:25 +0530 > From: Nikhil Rao <nikhil....@intel.com> > To: jerin.ja...@caviumnetworks.com, bruce.richard...@intel.com > CC: gage.e...@intel.com, dev@dpdk.org, tho...@monjalon.net, > harry.van.haa...@intel.com, hemant.agra...@nxp.com, nipun.gu...@nxp.com, > narender.vang...@intel.com, erik.g.carri...@intel.com, > abhinandan.guj...@intel.com, Nikhil Rao <nikhil....@intel.com> > Subject: [PATCH v3 0/4] eventdev: cover letter: ethernet Rx queue event > adapter > X-Mailer: git-send-email 2.7.4 > > 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 patchset introduces an ethernet Rx event adapter that dequeues packets > from ethernet devices and enqueues them to event devices. This patch is based > on > a previous RFC[2] and supercedes [3], the main difference being that > this version implements a common abstraction for HW and SW based packet > transfers. > > The adapter is designed to work with the EAL service core[4] for SW based > packet transfers. An eventdev PMD callback is used to determine that SW > based packet transfer service is required. The application can discover > and configure the service with a core mask using rte_service APIs. > > The adapter can service multiple ethernet devices and queues. For SW based > packet transfers 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.
Hi Nikhil. Overall this series looks good. The patch specific comments, I will send on each patches. Please fix the 1) ./devtools/check-git-log.sh & ./devtools/checkpatches.sh issues with series 2) I guess for next revision you could split the patches to more fine granularity with make sure each patch build separately.
