On Wed, Jun 29, 2016 at 05:10:31PM +0530, Jerin Jacob wrote:

On Wed, Jun 29, 2016 at 01:25:35PM +0200, Thomas Monjalon wrote:

quoted

2016-06-29 16:48, Jerin Jacob:

quoted

On Mon, Jun 27, 2016 at 04:59:42PM +0200, Thomas Monjalon wrote:

quoted

2016-06-27 20:18, Jerin Jacob:

quoted

On Mon, Jun 27, 2016 at 04:19:57PM +0200, Thomas Monjalon wrote:

quoted

2016-06-27 17:24, Jerin Jacob:

quoted

--- a/config/common_base
+++ b/config/common_base

@@ -267,6 +267,7 @@ CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
 CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
 CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
 CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
+CONFIG_RTE_LIBRTE_VIRTIO_INC_VECTOR=y

I don't remember what means INC_VECTOR?
Why a config option is needed for vector implementations?

I thought of adding additional configuration option(INC_VECTOR) _apart_ from
cpu flag based scheme in the patch because even though if a given platform
has cpu instruction support, in some platforms scalar version may
perform well wrt vector version(based on instruction latency, emulation required or not
etc). So a top level flag INC_VECTOR, can override the vector selection
for a given platform if required.

Isn't it a runtime driver option needed to disable vector virtio?

quoted

Regarding INC_VECTOR(INC in vector configuration name, I have no idea, I
followed the existing flags)
$ grep "INC_VECTOR" config/common_base
CONFIG_RTE_IXGBE_INC_VECTOR=y
CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=y
CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y

If the flag is really needed I would suggest VIRTIO_VECTOR.

OK I will change to VIRTIO_VECTOR

I would prefer a runtime option.

+1

OK

The platform I test their was NO need for additional VIRTIO_VECTOR
configuration as NEON versions outperforms than scalar version.

I thought of adding this option to override for any platform if it need
to accommodate such platform differences NEON vs scalar versions.

I will change completely to run-time detection based on cpuflags for IA and ARM.
Any objections?

Nope from me.

	--yliu