-----Original Message-----
> Date: Sat, 7 Oct 2017 02:39:54 +0530
> From: Nikhil Rao <[email protected]>
> To: [email protected], [email protected]
> CC: [email protected]
> Subject: [PATCH v5 0/7] eventdev: cover letter: eth Rx 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.
Hi Nikhil,
- Please re base to dpdk-next-eventdev
- There is one check-git-long error. Please fix it
Wrong headline lowercase:
eventdev: add event type for eth rx adapter
- You are planning to send the programmer guide with version. Right?
Are planning to send now or post RC1 ?
- For it looks OK to pull in next-eventdev, after fixing the
http://dpdk.org/ml/archives/dev/2017-October/077915.html and exiting
comments
CC: Hemant Agrawal <[email protected]>
CC: Nipun Gupta <[email protected]>
Does any have any objection to pull this in RC1 if Nikhil sends the next
version in time?
