[dpdk-dev] [PATCH v8 4/4] doc: update with link changes
On 18 February 2016 at 19:14, Mcnamara, John wrote: > Hi, > > Some minor comments below in order to get a consistent set of release > notes. > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc Sune > > Sent: Sunday, February 14, 2016 10:18 PM > > To: dev at dpdk.org; Lu, Wenzhuo ; Zhang, Helin > > ; Harish Patil ; Chen, > > Jing D > > Subject: [dpdk-dev] [PATCH v8 4/4] doc: update with link changes > > > > Add new features, ABI changes and resolved issues notice for the > > refactored link patch. > > > > Signed-off-by: Marc Sune > > --- > > doc/guides/rel_notes/release_2_3.rst | 102 > > This should be rebased and the notes added to > doc/guides/rel_notes/release_16_04.rst. > > > > + > > +* **ethdev: define a set of advertised link speeds.** > > The title and the text should be in the past tense. > > > See the hints/guidelines in the updated release notes: > > > http://dpdk.org/browse/dpdk/tree/doc/guides/rel_notes/release_16_04.rst > > > > + > > + Allowing to define a set of advertised speeds for auto-negociation, > > Maybe something like: Added functionality to allow the definition of > advertised speeds for ... > > > > > +* **ethdev: add speed_cap bitmap to recover eth device link speed > > +capabilities > > + define a set of advertised link speeds.** > > The title is a little long. Just give a brief overview here and more the > detail > to the text sections. > > > + > > + ``struct rte_eth_dev_info`` has now speed_cap bitmap, which allows > > + the application to recover the supported speeds for that ethernet > > device. > > It would be good to use quotes on speed_cap as well for consistency. > > > + > > +Examples > > + > > + > > +* New API call, rte_eth_speed_to_bm_flag(), in ethdev to map numerical > > +speeds to bitmap fields. > > I don't think this should be in the "Examples" section. Maybe as a sub-item > in the "New Featrues" or in "API Changes" if it is a change. > > > + > > +ABI Changes > > +--- > > + > > +* The ethdev rte_eth_link and rte_eth_conf structures were changed to > > + support the new link API, as well as ETH_LINK_HALF/FULL_DUPLEX. > > + > > +* The ethdev rte_eth_dev_info was changed to support device speed > > capabilities. > > Better to put the struct names and variables in quotes. > > Thanks, > Noted and fixed in v9. Thanks marc > > John. > - > > > >
[dpdk-dev] [PATCH] ixgbe: fix ixgbevf RX/TX function assignment
For the secondary process of DPDK to initialize ixgbevf, it will always
use the simple RX function or LRO RX function, and this behavior is not
the same RX/TX function selection logic as it is for the primary process,
so use the ixgbe_set_tx_function and ixgbe_set_rx_function to select the
RX/TX function when secondary process call the init function for eth dev.
Signed-off-by: Zhe Tao
---
drivers/net/ixgbe/ixgbe_ethdev.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 3e6fe86..0f9d048 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1278,8 +1278,21 @@ eth_ixgbevf_dev_init(struct rte_eth_dev *eth_dev)
* has already done this work. Only check we don't need a different
* RX function */
if (rte_eal_process_type() != RTE_PROC_PRIMARY){
- if (eth_dev->data->scattered_rx)
- eth_dev->rx_pkt_burst =
ixgbe_recv_pkts_lro_single_alloc;
+ struct ixgbe_tx_queue *txq;
+ /* TX queue function in primary, set by last queue initialized
+* Tx queue may not initialized by primary process
+*/
+ if (eth_dev->data->tx_queues) {
+ txq =
eth_dev->data->tx_queues[eth_dev->data->nb_tx_queues-1];
+ ixgbe_set_tx_function(eth_dev, txq);
+ } else {
+ /* Use default TX function if we get here */
+ PMD_INIT_LOG(NOTICE, "No TX queues configured yet. "
+"Using default TX function.");
+ }
+
+ ixgbe_set_rx_function(eth_dev);
+
return 0;
}
--
2.1.4
[dpdk-dev] [PATCH] arm: fix name armv7-a used for dpdk purposes
2016-02-16 19:35, Jan Viktorin: > The CONFIG_RTE_MACHINE must not contain hyphens to work correctly. This was > initially done only for the file name defconfig_arm-armv7a-linuxapp-gcc. This > patch fixes install-sdk goal. Otherwise, it creates a wrong directory for this > platform. > > Signed-off-by: Jan Viktorin Applied, thanks
[dpdk-dev] [PATCH] example/vhost: fix failed to allocate mbufs
2016-02-18 08:08, Jianfeng Tan: > In all, it fails to include master core's mbuf mempool cache. > > Signed-off-by: Jianfeng Tan > Reported-by: Qian Xu minor note: please keep the "people-tags" in the chronological order. Here the "Reported-by" is moved before the "Signed-off-by". [...] > +* **examples/vhost: fix failed to allocate mbuf.** > + > + vhost-switch often fails to allocate mbuf when dequeue from vring because > it > + wrongly calculate the number of mbufs needed. Reworded to comply with release notes style. Applied, thanks
[dpdk-dev] [PATCH] examples/vhost: fix out of sequence packets
2016-01-20 10:47, Yuanhan Liu: > On Wed, Jan 20, 2016 at 03:18:11AM +0800, Jianfeng Tan wrote: > > Issue description: when packets go through vhost example to virtio > > device and come back to another virtio device or physical NIC, the > > sequence of packets will be changed. > > > > Reported-by: Thomas Long > > Signed-off-by: Jianfeng Tan > > Acked-by: Yuanhan Liu Applied, thanks
[dpdk-dev] [PATCH 1/3] rte_interrupts: add rte_eal_intr_exit to shut down IRQ thread
2016-02-13 13:38, Matthew Hall: > There is no good way to shut down this thread from an application signal > handler. Here we add an rte_eal_intr_exit() function to allow this. Please Cunming, Would you have time to review this series about interrupt thread? Thank you
[dpdk-dev] [PATCH] eal: make resource initialization more robust
Hi, 2016-01-29 19:22, Jianfeng Tan: > Current issue: DPDK is not that friendly to container environment, which > caused by that it pre-alloc resource like cores and hugepages. But there > are this or that resource limitations, for examples, cgroup, rlimit, > cpuset, etc. > > For cores, this patch makes use of pthread_getaffinity_np to further > narrow down detected cores before parsing coremask (-c), corelist (-l), > and coremap (--lcores). > > For hugepages, this patch adds a recover mechanism to the case that > there are no that many hugepages can be used. It relys on a mem access > to fault-in hugepages, and if fails with SIGBUS, recover to previously > saved stack environment with siglongjmp(). They are some interesting ideas. However, I am not sure a library should try to be so smart silently. It needs more feedback to decide wether it can be the default behaviour or an option. Please send coremask and hugepage mapping as separate patches as they are totally different and may be integrated separately. Thanks
[dpdk-dev] [PATCH] mk: add makefile extention support
Hi, 2016-02-09 11:35, Keith Wiles: > Adding support to the build system to allow for Makefile.XXX > extention to a subtree, which already has Makefiles. These > Makefiles could be from the autotools and others places. Using > the Makefile extention RTE_MKFILE_SUFFIX in a makefile subtree > using 'export RTE_MKFILE_SUFFIX=.XXX' to use Makefile.XXX in > that subtree. > > The main reason I needed this feature was to integrate a autotool > open source projects with DPDK and keep the original Makefiles. Sorry I fail to understand why it is needed. Are you trying to add autotool in DPDK? I don't think it is a good approach. The DPDK must provide a pkgconfig interface to be integrated anywhere.
[dpdk-dev] [PATCH v2] examples/l3fwd: exact-match rework
Hi, There is an error when compiling: examples/l3fwd/l3fwd_em.c:304:1: error: unused function 'l3fwd_em_simple_forward' 2016-02-24 10:48, Tomasz Kulasek: > - l3fwd_em_simple_forward(pkts_burst[j], portid, qconf); > - l3fwd_em_simple_forward(pkts_burst[j+1], portid, > qconf); > - l3fwd_em_simple_forward(pkts_burst[j+2], portid, > qconf); > - l3fwd_em_simple_forward(pkts_burst[j+3], portid, > qconf); > - l3fwd_em_simple_forward(pkts_burst[j+4], portid, > qconf); > - l3fwd_em_simple_forward(pkts_burst[j+5], portid, > qconf); > - l3fwd_em_simple_forward(pkts_burst[j+6], portid, > qconf); > - l3fwd_em_simple_forward(pkts_burst[j+7], portid, > qconf);
[dpdk-dev] [PATCH v4 1/1] examples/l3fwd: modify and modularize l3fwd code
2016-02-25 11:24, Piotr Azarewicz: > Signed-off-by: Ravi Kerur > Signed-off-by: Piotr Azarewicz > > Tested-by: Tomasz Kulasek > Acked-by: Tomasz Kulasek > Acked-by: Konstantin Ananyev Applied, thanks
[dpdk-dev] [PATCH] mk: add makefile extention support
>Hi, > >2016-02-09 11:35, Keith Wiles: >> Adding support to the build system to allow for Makefile.XXX >> extention to a subtree, which already has Makefiles. These >> Makefiles could be from the autotools and others places. Using >> the Makefile extention RTE_MKFILE_SUFFIX in a makefile subtree >> using 'export RTE_MKFILE_SUFFIX=.XXX' to use Makefile.XXX in >> that subtree. >> >> The main reason I needed this feature was to integrate a autotool >> open source projects with DPDK and keep the original Makefiles. > >Sorry I fail to understand why it is needed. >Are you trying to add autotool in DPDK? I don't think it is a good approach. >The DPDK must provide a pkgconfig interface to be integrated anywhere. I was not trying to add autotools to DPDK. On a number of times I wanted to integrate a open source project(s) with DPDK and use DPDK?s build system, but because the open source project already contained Makefile files you can not use DPDK build system without modify or moving the original Makefile files. Using this method I can just add a exported variable and supply my own Makefile.XXX files. One case was building FreeBSD source, but I did not want to modify FreeBSD Makefiles (or reply on previous built Makefiles as they would not work on Linux anyway) as I was pulling the source down from freebsd.org repo. Using a patch to add the Makefiles with a different suffix allows me to build FreeBSD using DPDK, without having to modify or own the FreeBSD source. I have had this problem a number of times with open source code I did not want to modify, but just build within DPDK build system and adding the support for a different suffix to DPDK provided a clean way. The change does not effect the correct build system and just allows someone to define a new suffix for a given subtree in the code. > Regards, Keith
[dpdk-dev] [PATCH v7] mbuf: provide rte_pktmbuf_alloc_bulk API
v7 changes:
rte_pktmbuf_alloc_bulk isn't exported as API, so shouldn't be listed in
version map
v6 changes:
reflect the changes in release notes and library version map file
revise our duff's code style a bit to make it more readable
v5 changes:
add comment about duff's device and our variant implementation
v3 changes:
move while after case 0
add context about duff's device and why we use while loop in the commit
message
v2 changes:
unroll the loop a bit to help the performance
rte_pktmbuf_alloc_bulk allocates a bulk of packet mbufs.
There is related thread about this bulk API.
http://dpdk.org/dev/patchwork/patch/4718/
Thanks to Konstantin's loop unrolling.
Attached the wiki page about duff's device. It explains the performance
optimization through loop unwinding, and also the most dramatic use of
case label fall-through.
https://en.wikipedia.org/wiki/Duff%27s_device
In this implementation, while() loop is used because we could not assume
count is strictly positive. Using while() loop saves one line of check.
Signed-off-by: Gerald Rogers
Signed-off-by: Huawei Xie
Acked-by: Konstantin Ananyev
Acked-by: Olivier Matz
---
doc/guides/rel_notes/release_16_04.rst | 3 ++
lib/librte_mbuf/rte_mbuf.h | 55 ++
2 files changed, 58 insertions(+)
diff --git a/doc/guides/rel_notes/release_16_04.rst
b/doc/guides/rel_notes/release_16_04.rst
index e2219d0..b10a11b 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -46,6 +46,9 @@ This section should contain new features added in this
release. Sample format:
* **Added vhost-user live migration support.**
+* **Enable bulk allocation of mbufs.**
+ A new function ``rte_pktmbuf_alloc_bulk()`` has been added to allow the user
+ to allocate a bulk of mbufs.
Resolved Issues
---
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index c973e9b..c1f6bc4 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -1336,6 +1336,61 @@ static inline struct rte_mbuf *rte_pktmbuf_alloc(struct
rte_mempool *mp)
}
/**
+ * Allocate a bulk of mbufs, initialize refcnt and reset the fields to default
+ * values.
+ *
+ * @param pool
+ *The mempool from which mbufs are allocated.
+ * @param mbufs
+ *Array of pointers to mbufs
+ * @param count
+ *Array size
+ * @return
+ * - 0: Success
+ */
+static inline int rte_pktmbuf_alloc_bulk(struct rte_mempool *pool,
+struct rte_mbuf **mbufs, unsigned count)
+{
+ unsigned idx = 0;
+ int rc;
+
+ rc = rte_mempool_get_bulk(pool, (void **)mbufs, count);
+ if (unlikely(rc))
+ return rc;
+
+ /* To understand duff's device on loop unwinding optimization, see
+* https://en.wikipedia.org/wiki/Duff's_device.
+* Here while() loop is used rather than do() while{} to avoid extra
+* check if count is zero.
+*/
+ switch (count % 4) {
+ case 0:
+ while (idx != count) {
+ RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
+ rte_mbuf_refcnt_set(mbufs[idx], 1);
+ rte_pktmbuf_reset(mbufs[idx]);
+ idx++;
+ case 3:
+ RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
+ rte_mbuf_refcnt_set(mbufs[idx], 1);
+ rte_pktmbuf_reset(mbufs[idx]);
+ idx++;
+ case 2:
+ RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
+ rte_mbuf_refcnt_set(mbufs[idx], 1);
+ rte_pktmbuf_reset(mbufs[idx]);
+ idx++;
+ case 1:
+ RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
+ rte_mbuf_refcnt_set(mbufs[idx], 1);
+ rte_pktmbuf_reset(mbufs[idx]);
+ idx++;
+ }
+ }
+ return 0;
+}
+
+/**
* Attach packet mbuf to another packet mbuf.
*
* After attachment we refer the mbuf we attached as 'indirect',
--
1.8.1.4
[dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module
On 2/28/2016 3:34 PM, Avi Kivity wrote: > On 01/27/2016 06:24 PM, Ferruh Yigit wrote: >> This kernel module is based on KNI module, but this one is stripped >> version of it and only for control messages, no data transfer >> functionality provided. >> >> This Linux kernel module helps userspace application create virtual >> interfaces and when a control command issued into that virtual >> interface, module pushes the command to the userspace and gets the >> response back for the caller application. >> >> The Linux tools like ethtool/ifconfig/ip can be used on virtual >> interfaces but not ones for related data, like tcpdump. >> >> In long term this patch intends to replace the KNI and KNI will be >> depreciated. > > Instead of adding yet another out-of-tree kernel module, why not extend > the existing in-tree tap driver? This will make everyone's life easier. > > Since tap also supports data transfer, an application can also forward > packets not intended to it to the kernel, and forward packets from the > kernel through the device. > Hi Avi, KDP (Kernel Data Path) does what you have described, it is implemented as PMD and it benefits from tap driver to data transfer through the kernel. It also support custom kernel module for better performance. For KCP (Kernel Control Path), network driver forwards control commands to the userspace driver, I doubt this is something wanted for tun/tap driver, so extending tun/tap driver like this can be hard to upstream. We are investigating about adding a native support to Linux kernel for KCP, but there is no task started for this right now, any support is welcome. Thanks, ferruh
[dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module
On 01/27/2016 06:24 PM, Ferruh Yigit wrote: > This kernel module is based on KNI module, but this one is stripped > version of it and only for control messages, no data transfer > functionality provided. > > This Linux kernel module helps userspace application create virtual > interfaces and when a control command issued into that virtual > interface, module pushes the command to the userspace and gets the > response back for the caller application. > > The Linux tools like ethtool/ifconfig/ip can be used on virtual > interfaces but not ones for related data, like tcpdump. > > In long term this patch intends to replace the KNI and KNI will be > depreciated. Instead of adding yet another out-of-tree kernel module, why not extend the existing in-tree tap driver? This will make everyone's life easier. Since tap also supports data transfer, an application can also forward packets not intended to it to the kernel, and forward packets from the kernel through the device. > Signed-off-by: Ferruh Yigit > --- > config/common_linuxapp | 6 + > lib/librte_eal/linuxapp/Makefile | 5 +- > lib/librte_eal/linuxapp/eal/Makefile | 3 +- > .../linuxapp/eal/include/exec-env/rte_kcp_common.h | 86 +++ > lib/librte_eal/linuxapp/kcp/Makefile | 58 + > lib/librte_eal/linuxapp/kcp/kcp_dev.h | 65 + > lib/librte_eal/linuxapp/kcp/kcp_ethtool.c | 261 +++ > lib/librte_eal/linuxapp/kcp/kcp_misc.c | 282 > + > lib/librte_eal/linuxapp/kcp/kcp_net.c | 209 +++ > lib/librte_eal/linuxapp/kcp/kcp_nl.c | 194 ++ > 10 files changed, 1167 insertions(+), 2 deletions(-) > create mode 100644 > lib/librte_eal/linuxapp/eal/include/exec-env/rte_kcp_common.h > create mode 100644 lib/librte_eal/linuxapp/kcp/Makefile > create mode 100644 lib/librte_eal/linuxapp/kcp/kcp_dev.h > create mode 100644 lib/librte_eal/linuxapp/kcp/kcp_ethtool.c > create mode 100644 lib/librte_eal/linuxapp/kcp/kcp_misc.c > create mode 100644 lib/librte_eal/linuxapp/kcp/kcp_net.c > create mode 100644 lib/librte_eal/linuxapp/kcp/kcp_nl.c > > diff --git a/config/common_linuxapp b/config/common_linuxapp > index 74bc515..5d5e3e4 100644 > --- a/config/common_linuxapp > +++ b/config/common_linuxapp > @@ -503,6 +503,12 @@ CONFIG_RTE_KNI_VHOST_DEBUG_RX=n > CONFIG_RTE_KNI_VHOST_DEBUG_TX=n > > # > +# Compile librte_ctrl_if > +# > +CONFIG_RTE_KCP_KMOD=y > +CONFIG_RTE_KCP_KO_DEBUG=n > + > +# > # Compile vhost library > # fuse-devel is needed to run vhost-cuse. > # fuse-devel enables user space char driver development > diff --git a/lib/librte_eal/linuxapp/Makefile > b/lib/librte_eal/linuxapp/Makefile > index d9c5233..d1fa3a3 100644 > --- a/lib/librte_eal/linuxapp/Makefile > +++ b/lib/librte_eal/linuxapp/Makefile > @@ -1,6 +1,6 @@ > # BSD LICENSE > # > -# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. > +# Copyright(c) 2010-2016 Intel Corporation. All rights reserved. > # All rights reserved. > # > # Redistribution and use in source and binary forms, with or without > @@ -38,6 +38,9 @@ DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal > ifeq ($(CONFIG_RTE_KNI_KMOD),y) > DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += kni > endif > +ifeq ($(CONFIG_RTE_KCP_KMOD),y) > +DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += kcp > +endif > ifeq ($(CONFIG_RTE_LIBRTE_XEN_DOM0),y) > DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += xen_dom0 > endif > diff --git a/lib/librte_eal/linuxapp/eal/Makefile > b/lib/librte_eal/linuxapp/eal/Makefile > index 26eced5..dded8cb 100644 > --- a/lib/librte_eal/linuxapp/eal/Makefile > +++ b/lib/librte_eal/linuxapp/eal/Makefile > @@ -1,6 +1,6 @@ > # BSD LICENSE > # > -# Copyright(c) 2010-2015 Intel Corporation. All rights reserved. > +# Copyright(c) 2010-2016 Intel Corporation. All rights reserved. > # All rights reserved. > # > # Redistribution and use in source and binary forms, with or without > @@ -116,6 +116,7 @@ CFLAGS_eal_thread.o += -Wno-return-type > endif > > INC := rte_interrupts.h rte_kni_common.h rte_dom0_common.h > +INC += rte_kcp_common.h > > SYMLINK-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP)-include/exec-env := \ > $(addprefix include/exec-env/,$(INC)) > diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kcp_common.h > b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kcp_common.h > new file mode 100644 > index 000..b3a6ee3 > --- /dev/null > +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kcp_common.h > @@ -0,0 +1,86 @@ > +/*- > + * This file is provided under a dual BSD/LGPLv2 license. When using or > + * redistributing this file, you may do so under either license. > + * > + * GNU LESSER GENERAL PUBLIC LICENSE > + * > + * Copyright(c) 2016 Intel Corporation. All rights reserved. > + * > + * This program is fr
[dpdk-dev] RSS Hash using 2 tuple
Hi All, I tried to change L3fwd program. My aim is to use only destination IP and UDP protocol as only 2 tuple in RSS hash. My first question is, Is it possible? I have checked macros that doesn't give me impression that we can just use destination IP. Please correct me if i am wrong. Thanks in advance. -- Rgds, Nishant
[dpdk-dev] [PATCH] i40e: Fix a typo.
> -Original Message-
> From: Rosen, Rami
> Sent: Saturday, February 27, 2016 2:34 AM
> To: Zhang, Helin
> Cc: dev at dpdk.org; Rosen, Rami
> Subject: [PATCH] i40e: Fix a typo.
>
> This patch fixes a typo in a comment in the definition of the i40e_pf struct.
>
> Signed-off-by: Rami Rosen
Acked-by: Helin Zhang
> ---
> drivers/net/i40e/i40e_ethdev.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
> index 6edd7dd..8ebac9d 100644
> --- a/drivers/net/i40e/i40e_ethdev.h
> +++ b/drivers/net/i40e/i40e_ethdev.h
> @@ -408,7 +408,7 @@ struct i40e_pf {
>
> struct rte_eth_dev_data *dev_data; /* Pointer to the device data */
> struct ether_addr dev_addr; /* PF device mac address */
> - uint64_t flags; /* PF featuer flags */
> + uint64_t flags; /* PF feature flags */
> /* All kinds of queue pair setting for different VSIs */
> struct i40e_pf_vf *vfs;
> uint16_t vf_num;
> --
> 2.5.0
[dpdk-dev] VIRTIO interface with DPDK in Guest VM not receiving packets
Hello , I have observed that QEMU/Host does not pass the packets to Guest VM on Virtio interfaces unless I turn on promisc mode on the interface in the Guest. Host is running RHEL 7.2. Have tried with Ubuntu 14.4 as well . No DPDK-OVS or any vhost-user. Is this expected behavior? I would not assume this should be. Any pointers to look into? Thanks and Regards, Ajeet
