eventdev: introduce burst mode capability

eventdev: introduce burst mode capability

Introducing the burst mode capability flag to express the event device
is capable of operating in burst mode for enqueue(forward, release) and
dequeue operation. If the device is not capable, then the application
still uses the rte_event_dequeue_burst() and rte_event_enqueue_burst()
but PMD accepts only one event at a time which is any way transparent
with the current rte_event_*_burst API semantics.

It solves two purposes:
1) Fix performance regression on the PMD which supports only nonburst
mode, and this issue is two-fold.

Typically the burst_worker main loop consists of following pseudo code:

while(1)
{
	uint16_t nb_rx = rte_event_dequeue_burst(ev,..);

	for (i=0; i < nb_rx; i++) {
		process(ev[i]);
		if (is_release_required(ev[i]))
			release_the_event(ev);
	}

        uint16_t nb_tx = rte_event_enqueue_burst(dev_id, port_id,
                                events, nb_rx);
        while (nb_tx < nb_rx)
            nb_tx += rte_event_enqueue_burst(dev_id, port_id,
            events + nb_tx, nb_rx - nb_tx);
}

Typically the non_burst_worker main loop consists of following pseudo code:
while(1)
{
    uint16_t nb_rx = rte_event_dequeue_burst(&ev, , 1);
    if (!nb_rx)
        continue;
    process(ev);
    while (rte_event_enqueue_burst(dev, port, &ev, 1) != 1);
}

Following overhead has been seen on nonburst mode capable PMDs with
burst mode version
- Extra explicit release(PMD does release on implicitly on next
dequeue) and thus avoids the cost additional driver function overhead.
- Extra "for" loop for event processing which compiler cannot detect at
runtime

2) Simplify the application configuration by avoiding the application to
find the correct enqueue and dequeue depth across different PMD.
If burst mode is not supported then, PMD can ignore depth field.
This will enable to write portable applications and makes
RFC eventdev_pipeline application works on OCTEONTX PMD
http://dpdk.org/dev/patchwork/patch/23799/

If an application wishes to get the maximum performance on nonburst
capable PMD then the application can write the code in a way that by
keeping packet processing function as inline functions and launch the
workers based on the capability.
The generic burst based worker still work on those PMDs without
any code change but this scheme needed only when the application wants
to gets the maximum performance out of nonburst capable PMDs.

This patch is based the on the real world test cases
http://dpdk.org/dev/patchwork/patch/24832/, Where without this scheme
20.9% performance drop observed per core.

See worker_wrapper(), perf_queue_worker(), perf_queue_worker_burst()
functions to use this scheme in a portable way without losing performance
on both sets of PMDs and achieving the portability.
http://dpdk.org/dev/patchwork/patch/24832/

Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>