[dpdk-dev] [PATCH v1 09/15] malloc: fix the issue of SOCKET_ID_ANY

[Stephen Hemminger]

On Thu, 22 Jan 2015 16:16:32 +0800
Cunming Liang  wrote:

> - return rte_socket_id();
> + unsigned socket_id = rte_socket_id();
> +
> + if (socket_id == (unsigned)SOCKET_ID_ANY)

I prefer not casting -1 to unsigned it will cause warnings.
It is better to make socket_id an integer and then have
the implicit cast in the return.

[dpdk-dev] [PATCH v3 05/18] librte_acl: fix a bug at build phase that can cause matches beeing overwirtten.

[Ananyev, Konstantin]

Hi Neil,

> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Sunday, January 25, 2015 5:35 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 05/18] librte_acl: fix a bug at build phase 
> that can cause matches beeing overwirtten.
> 
> On Tue, Jan 20, 2015 at 06:40:54PM +, Konstantin Ananyev wrote:
> > Signed-off-by: Konstantin Ananyev 
> > ---
> >  lib/librte_acl/acl_bld.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_acl/acl_bld.c b/lib/librte_acl/acl_bld.c
> > index 8bf4a54..22f7934 100644
> > --- a/lib/librte_acl/acl_bld.c
> > +++ b/lib/librte_acl/acl_bld.c
> > @@ -1907,7 +1907,7 @@ rte_acl_build(struct rte_acl_ctx *ctx, const struct 
> > rte_acl_config *cfg)
> > bcx.num_tries, bcx.cfg.num_categories,
> > RTE_ACL_MAX_FIELDS * RTE_DIM(bcx.tries) *
> > sizeof(ctx->data_indexes[0]),
> > -   bcx.num_build_rules);
> > +   bcx.num_build_rules + 1);
> > if (rc == 0) {
> >
> > /* set data indexes. */
> > --
> > 1.8.5.3
> >
> >
> Shouldn't you add to num_build_rules inside rte_acl_gen?  That way other 
> future
> users of the function don't have to remember to do so.

In that patch, I just fix the bug to stop generate invalid tries for some 
corener cases.
In the later patch in that set, I did something similar to what you are 
suggesting here -
make rte_acl_gen() to allocate indexes for all match nodes too (as it already 
doing for all other nodes).
See  [PATCH v3 07/18] librte_acl: build/gen phase - simplify the way match 
nodes are allocated.

Konstantin

> Neil

[dpdk-dev] [PATCH 0/4] DPDK memcpy optimization

[Luke Gorrie]

Hi John,

On 19 January 2015 at 02:53,  wrote:

> This patch set optimizes memcpy for DPDK for both SSE and AVX platforms.
> It also extends memcpy test coverage with unaligned cases and more test
> points.
>

I am really interested in this work you are doing on memory copies
optimized for packet data. I would like to understand it in more depth. I
have a lot of questions and ideas but let me try to keep it simple for now
:-)

How do you benchmark? where does the "factor of 2-8" cited elsewhere in the
thread come from? how can I reproduce? what results are you seeing compared
with libc?

I did a quick benchmark this weekend based on cachebench
. This seems like
a fairly weak benchmark (always L1 cache, always same alignment, always
predictable branches). Do you think this is relevant? How does this compare
with your results?

I compared:
  rte_memcpy (the new optimized one compiled with gcc-4.9 and -march=native
and -O3)
  memcpy from glibc 2.19 (ubuntu 14.04)
  memcpy from glibc 2.20 (arch linux)

on hardware:
  E5-2620v3 (Haswell)
  E5-2650 (Sandy Bridge)

running cachebench like this:

./cachebench -p -e1 -x1 -m14


rte_memcpy.h on Haswell:

Memory Copy Library Cache Test

C Size  Nanosec MB/sec  % Chnge
--- --- --- ---
256 0.0189191.881.00
384 0.0196505.430.92
512 0.0196509.191.00
768 0.0191475.721.06
10240.0196293.820.95
15360.0196521.661.00
20480.0196522.871.00
30720.0196525.531.00
40960.0196522.791.00
61440.0196507.711.00
81920.0194584.411.02
12288   0.0195062.800.99
16384   0.0180493.461.18


libc 2.20 on Haswell:

Memory Copy Library Cache Test

C Size  Nanosec MB/sec  % Chnge
--- --- --- ---
256 0.0165978.641.00
384 0.01100249.01   0.66
512 0.01123476.55   0.81
768 0.01144699.86   0.85
10240.01159459.88   0.91
15360.01168001.92   0.95
20480.0180738.312.08
30720.0180270.021.01
40960.0184239.840.95
61440.0190600.130.93
81920.0189767.941.01
12288   0.0192085.980.97
16384   0.0192719.950.99


libc 2.19 on Haswell:

Memory Copy Library Cache Test

C Size  Nanosec MB/sec  % Chnge
--- --- --- ---
256 0.0259871.691.00
384 0.0168545.940.87
512 0.0172674.230.94
768 0.0179257.470.92
10240.0179740.430.99
15360.0185483.670.93
20480.0187703.680.97
30720.0186685.711.01
40960.0187147.840.99
61440.0168622.961.27
81920.0170591.250.97
12288   0.0172621.280.97
16384   0.0167713.631.07


rte_memcpy on Sandy Bridge:

Memory Copy Library Cache Test

C Size Nanosec MB/sec % Chnge
--- --- --- ---
256 0.0262158.191.00
384 0.0173256.410.85
512 0.0182032.160.89
768 0.0173919.921.11
10240.0175937.510.97
15360.0178280.200.97
20480.0179562.540.98
30720.0180800.930.98
40960.0181453.710.99
61440.0181915.840.99
81920.0182427.980.99
12288   0.0182789.821.00
16384   0.0167519.661.23



libc 2.20 on Sandy Bridge:

Memory Copy Library Cache Test

C Size Nanosec MB/sec % Chnge
--- --- --- ---
256 0.0248651.201.00
384 0.0257653.910.84
512 0.0167909.770.85
768 0.0171177.750.95
10240.01   

[dpdk-dev] [PATCH v1 02/15] eal: new eal option '--lcores' for cpu assignment

[Liang, Cunming]

Hi Pawel,

I don't see much different there.
If replacing '@' to '.'; '()' to '[]'; and ',' to '/'; they're almost the same.
Without having rx/tx case, so ':' is useless in our case.
Considering the semantic, '@'(at) is more readable than '.' for core assignment.

-Liang Cunming

> -Original Message-
> From: Wodkowski, PawelX
> Sent: Thursday, January 22, 2015 11:17 PM
> To: Ananyev, Konstantin; Richardson, Bruce; Liang, Cunming
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v1 02/15] eal: new eal option '--lcores' for 
> cpu
> assignment
> 
> Hi,
> I want to mention that similar but for me much more readable syntax have
> Pktgen-DPDK for defining core - port mapping. Maybe we can adopt this syntax
> for new '--lcores' parameter.
> 
> See '-m' parameter syntax on Pktgen readme.
> https://github.com/pktgen/Pktgen-DPDK/blob/master/dpdk/examples/pktgen/R
> EADME.md
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev, Konstantin
> > Sent: Thursday, January 22, 2015 3:34 PM
> > To: Richardson, Bruce; Liang, Cunming
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v1 02/15] eal: new eal option '--lcores' for 
> > cpu
> > assignment
> >
> > Hi Bruce,
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> > > Sent: Thursday, January 22, 2015 12:19 PM
> > > To: Liang, Cunming
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v1 02/15] eal: new eal option '--lcores' 
> > > for cpu
> > assignment
> > >
> > > On Thu, Jan 22, 2015 at 04:16:25PM +0800, Cunming Liang wrote:
> > > > It supports one new eal long option '--lcores' for EAL thread cpuset
> > assignment.
> > > >
> > > > The format pattern:
> > > > --lcores='lcores[@cpus]<,lcores[@cpus]>'
> > > > lcores, cpus could be a single digit or a group.
> > > > '(' and ')' are necessary if it's a group.
> > > > If not supply '@cpus', the value of cpus uses the same as lcores.
> > > >
> > > > e.g. '1,2@(5-7),(3-5)@(0,2),(0,6)' means starting 7 EAL thread as below
> > > >   lcore 0 runs on cpuset 0x41 (cpu 0,6)
> > > >   lcore 1 runs on cpuset 0x2 (cpu 1)
> > > >   lcore 2 runs on cpuset 0xe0 (cpu 5,6,7)
> > > >   lcore 3,4,5 runs on cpuset 0x5 (cpu 0,2)
> > > >   lcore 6 runs on cpuset 0x41 (cpu 0,6)
> > > >
> > >
> > > This strikes me as very confusing, though a couple of tweaks might help 
> > > with
> > > readability. The lcore 0 at the end is especially confusing.
> >
> > Didn't get you here: do you find (0,6) confusing, right?
> > Because braces implicitly specifies affinity for group of en-braced lcores?
> >
> > > Perhaps we can
> > > limit the allowed formats here,
> > > * require the lcore_id to be specified - the lack of an lcore id for the 
> > > last part
> > > makes having it as lcore 0 surprising.
> >
> > Again, not sure I understand you properly:  lcore_id(s) are always specified
> > explicitly.
> > Physical cpus part might be omitted.
> >
> > > * only allow one lcore id to be given for each set of cores.
> >
> > So you mean for '(3-5)@(0,2)' user would have to: '3@(0,2),4@(0,2),5@(0,2)'?
> > I don't see big difference here, but imagine you'd like to create a pool of 
> > 32 EAL-
> > threads running on same cpu set.
> > With current syntax it is just something like: '(32-63)@(0-7)'.
> > With what you proposing it will be a very long list.
> >
> > >
> > > I think it may still be readable if we allow the core set to be omitted 
> > > if its
> > > to be the same as the lcore_id.
> >
> > I think that is supported.
> > See lcore_id=1 in Steve's example above.
> > As I understand: --lcores='0,2,3-5' is equal to '-l 0,2,3-5' and to '-c 
> > 0x3d'.
> >
> > Konstantin
> >
> > >
> > > It's probably still not going to be very tidy, but I think we can improve 
> > > things.
> > >
> > > /Bruce
> > >
> > > > Signed-off-by: Cunming Liang 
> > > > ---
> > > >  lib/librte_eal/common/eal_common_launch.c  |   1 -
> > > >  lib/librte_eal/common/eal_common_options.c | 262
> > -
> > > >  lib/librte_eal/common/eal_options.h|   2 +
> > > >  lib/librte_eal/linuxapp/eal/Makefile   |   1 +
> > > >  4 files changed, 261 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/lib/librte_eal/common/eal_common_launch.c
> > b/lib/librte_eal/common/eal_common_launch.c
> > > > index 599f83b..2d732b1 100644
> > > > --- a/lib/librte_eal/common/eal_common_launch.c
> > > > +++ b/lib/librte_eal/common/eal_common_launch.c
> > > > @@ -117,4 +117,3 @@ rte_eal_mp_wait_lcore(void)
> > > > rte_eal_wait_lcore(lcore_id);
> > > > }
> > > >  }
> > > > -
> > > > diff --git a/lib/librte_eal/common/eal_common_options.c
> > b/lib/librte_eal/common/eal_common_options.c
> > > > index e2810ab..fc47588 100644
> > > > --- a/lib/librte_eal/common/eal_common_options.c
> > > > +++ b/lib/librte_eal/common/eal_common_options.c
> > > > @@ -45,6 +45,7 @@
> > > >  #include 
> > > >  #include 
> > > 

[dpdk-dev] [PATCH 4/4] lib/librte_eal: Optimized memcpy in arch/x86/rte_memcpy.h for both SSE and AVX platforms

[Jim Thompson]

> On Jan 20, 2015, at 11:15 AM, Stephen Hemminger  networkplumber.org> wrote:
> 
> On Mon, 19 Jan 2015 09:53:34 +0800
> zhihong.wang at intel.com wrote:
> 
>> Main code changes:
>> 
>> 1. Differentiate architectural features based on CPU flags
>> 
>>a. Implement separated move functions for SSE/AVX/AVX2 to make full 
>> utilization of cache bandwidth
>> 
>>b. Implement separated copy flow specifically optimized for target 
>> architecture
>> 
>> 2. Rewrite the memcpy function "rte_memcpy"
>> 
>>a. Add store aligning
>> 
>>b. Add load aligning based on architectural features
>> 
>>c. Put block copy loop into inline move functions for better control of 
>> instruction order
>> 
>>d. Eliminate unnecessary MOVs
>> 
>> 3. Rewrite the inline move functions
>> 
>>a. Add move functions for unaligned load cases
>> 
>>b. Change instruction order in copy loops for better pipeline utilization
>> 
>>c. Use intrinsics instead of assembly code
>> 
>> 4. Remove slow glibc call for constant copies
>> 
>> Signed-off-by: Zhihong Wang 
> 
> Dumb question: why not fix glibc memcpy instead?
> What is special about rte_memcpy?

In addition to the other points, a FreeBSD doesn't use glibc on the target 
platform, (but it is used on, say MIPS), and FreeBSD is a supported DPDK 
platform. 

So glibc isn't a solution. 

Jim

[dpdk-dev] [PATCH v2] vhost: add interface name to virtio-net struct

[Linhaifeng]

On 2014/12/19 2:07, ciara.loftus at intel.com wrote:
> From: Ciara Loftus 
> 
> This patch fixes the issue whereby when using userspace vhost ports
> in the context of vSwitching, the name provided to the hypervisor/QEMU
> of the vhost tap device needs to be exposed in the library, in order

Who create the tap device?When using vhost-user QEMU will not create it.

> for the vSwitch to be able to direct packets to the correct device.

Why not use unix domain socket path?

> This patch introduces an 'ifname' member to the virtio-net structure
> which is populated with the tap device name when QEMU is brought up
> with a vhost device.
> 
> Signed-off-by: Ciara Loftus 
> Signed-off-by: Anthony Fee 
> Acked-by: Huawei Xie 
> ---
>  lib/librte_vhost/rte_virtio_net.h |3 ++
>  lib/librte_vhost/virtio-net.c |   48 
> -
>  2 files changed, 50 insertions(+), 1 deletions(-)
> 
> diff --git a/lib/librte_vhost/rte_virtio_net.h 
> b/lib/librte_vhost/rte_virtio_net.h
> index 00b1328..0bf07c7 100644
> --- a/lib/librte_vhost/rte_virtio_net.h
> +++ b/lib/librte_vhost/rte_virtio_net.h
> @@ -43,6 +43,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> @@ -96,6 +98,7 @@ struct virtio_net {
>   uint64_tfeatures;   /**< Negotiated feature set. */
>   uint64_tdevice_fh;  /**< device identifier. */
>   uint32_tflags;  /**< Device flags. Only used to 
> check if device is running on data core. */
> + charifname[IFNAMSIZ];   /**< Name of the tap 
> device. */
>   void*priv;  /**< private context */
>  } __rte_cache_aligned;
>  
> diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
> index 852b6d1..7eae5ee 100644
> --- a/lib/librte_vhost/virtio-net.c
> +++ b/lib/librte_vhost/virtio-net.c
> @@ -43,6 +43,10 @@
>  #include 
>  #include 
>  
> +#include 
> +#include 
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -1000,6 +1004,46 @@ set_vring_kick(struct vhost_device_ctx ctx, struct 
> vhost_vring_file *file)
>  }
>  
>  /*
> + * Function to get the tap device name from the provided file descriptor and
> + * save it in the device structure.
> + */
> +static int
> +get_ifname(struct virtio_net *dev, int tap_fd, int pid)
> +{
> + struct eventfd_copy fd_tap;
> + struct ifreq ifr;
> + uint32_t size, ifr_size;
> + int ret;
> +
> + fd_tap.source_fd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
> + fd_tap.target_fd = tap_fd;
> + fd_tap.target_pid = pid;
> +
> + if (eventfd_copy(dev, &fd_tap))
> + return -1;
> +
> + ret = ioctl(fd_tap.source_fd, TUNGETIFF, &ifr);
> +
> + if (close(fd_tap.source_fd) < 0)
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "(%"PRIu64") fd close failed\n",
> + dev->device_fh);
> +
> + if (ret >= 0) {
> + ifr_size = strnlen(ifr.ifr_name, sizeof(ifr.ifr_name));
> + size = ifr_size > sizeof(dev->ifname)?
> + sizeof(dev->ifname): ifr_size;
> +
> + strncpy(dev->ifname, ifr.ifr_name, size);
> + } else
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "(%"PRIu64") TUNGETIFF ioctl failed\n",
> + dev->device_fh);
> +
> + return 0;
> +}
> +
> +/*
>   * Called from CUSE IOCTL: VHOST_NET_SET_BACKEND
>   * To complete device initialisation when the virtio driver is loaded,
>   * we are provided with a valid fd for a tap device (not used by us).
> @@ -1026,8 +1070,10 @@ set_backend(struct vhost_device_ctx ctx, struct 
> vhost_vring_file *file)
>*/
>   if (!(dev->flags & VIRTIO_DEV_RUNNING)) {
>   if (((int)dev->virtqueue[VIRTIO_TXQ]->backend != 
> VIRTIO_DEV_STOPPED) &&
> - ((int)dev->virtqueue[VIRTIO_RXQ]->backend != 
> VIRTIO_DEV_STOPPED))
> + ((int)dev->virtqueue[VIRTIO_RXQ]->backend != 
> VIRTIO_DEV_STOPPED)) {
> + get_ifname(dev, file->fd, ctx.pid);
>   return notify_ops->new_device(dev);
> + }
>   /* Otherwise we remove it. */
>   } else
>   if (file->fd == VIRTIO_DEV_STOPPED)
> 

-- 
Regards,
Haifeng

[dpdk-dev] [PATCH v3 05/18] librte_acl: fix a bug at build phase that can cause matches beeing overwirtten.

[Neil Horman]

On Tue, Jan 20, 2015 at 06:40:54PM +, Konstantin Ananyev wrote:
> Signed-off-by: Konstantin Ananyev 
> ---
>  lib/librte_acl/acl_bld.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_acl/acl_bld.c b/lib/librte_acl/acl_bld.c
> index 8bf4a54..22f7934 100644
> --- a/lib/librte_acl/acl_bld.c
> +++ b/lib/librte_acl/acl_bld.c
> @@ -1907,7 +1907,7 @@ rte_acl_build(struct rte_acl_ctx *ctx, const struct 
> rte_acl_config *cfg)
>   bcx.num_tries, bcx.cfg.num_categories,
>   RTE_ACL_MAX_FIELDS * RTE_DIM(bcx.tries) *
>   sizeof(ctx->data_indexes[0]),
> - bcx.num_build_rules);
> + bcx.num_build_rules + 1);
>   if (rc == 0) {
>  
>   /* set data indexes. */
> -- 
> 1.8.5.3
> 
> 
Shouldn't you add to num_build_rules inside rte_acl_gen?  That way other future
users of the function don't have to remember to do so.
Neil

[dpdk-dev] [PATCH v2] vhost: add interface name to virtio-net struct

[Xie, Huawei]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Linhaifeng
> Sent: Sunday, January 25, 2015 12:42 PM
> To: Loftus, Ciara; dev at dpdk.org
> Cc: Anthony Fee
> Subject: Re: [dpdk-dev] [PATCH v2] vhost: add interface name to virtio-net 
> struct
> 
> 
> 
> On 2014/12/19 2:07, ciara.loftus at intel.com wrote:
> > From: Ciara Loftus 
> >
> > This patch fixes the issue whereby when using userspace vhost ports
> > in the context of vSwitching, the name provided to the hypervisor/QEMU
> > of the vhost tap device needs to be exposed in the library, in order
> 
> Who create the tap device?When using vhost-user QEMU will not create it.
> 
> > for the vSwitch to be able to direct packets to the correct device.
> 
> Why not use unix domain socket path?

In this patch, for vhost-cuse, the ifname comes from the name of the tap device.
For vhost-user, ifname is the name of the socket path.

> 
> > This patch introduces an 'ifname' member to the virtio-net structure
> > which is populated with the tap device name when QEMU is brought up
> > with a vhost device.
> >
> > Signed-off-by: Ciara Loftus 
> > Signed-off-by: Anthony Fee 
> > Acked-by: Huawei Xie 
> > ---
> >  lib/librte_vhost/rte_virtio_net.h |3 ++
> >  lib/librte_vhost/virtio-net.c |   48
> -
> >  2 files changed, 50 insertions(+), 1 deletions(-)
> >
> > diff --git a/lib/librte_vhost/rte_virtio_net.h 
> > b/lib/librte_vhost/rte_virtio_net.h
> > index 00b1328..0bf07c7 100644
> > --- a/lib/librte_vhost/rte_virtio_net.h
> > +++ b/lib/librte_vhost/rte_virtio_net.h
> > @@ -43,6 +43,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >
> >  #include 
> >  #include 
> > @@ -96,6 +98,7 @@ struct virtio_net {
> > uint64_tfeatures;   /**< Negotiated feature set.
> */
> > uint64_tdevice_fh;  /**< device identifier. */
> > uint32_tflags;  /**< Device flags. Only used to
> check if device is running on data core. */
> > +   charifname[IFNAMSIZ];   /**< Name of the tap
> device. */
> > void*priv;  /**< private context */
> >  } __rte_cache_aligned;
> >
> > diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
> > index 852b6d1..7eae5ee 100644
> > --- a/lib/librte_vhost/virtio-net.c
> > +++ b/lib/librte_vhost/virtio-net.c
> > @@ -43,6 +43,10 @@
> >  #include 
> >  #include 
> >
> > +#include 
> > +#include 
> > +#include 
> > +
> >  #include 
> >  #include 
> >  #include 
> > @@ -1000,6 +1004,46 @@ set_vring_kick(struct vhost_device_ctx ctx, struct
> vhost_vring_file *file)
> >  }
> >
> >  /*
> > + * Function to get the tap device name from the provided file descriptor 
> > and
> > + * save it in the device structure.
> > + */
> > +static int
> > +get_ifname(struct virtio_net *dev, int tap_fd, int pid)
> > +{
> > +   struct eventfd_copy fd_tap;
> > +   struct ifreq ifr;
> > +   uint32_t size, ifr_size;
> > +   int ret;
> > +
> > +   fd_tap.source_fd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
> > +   fd_tap.target_fd = tap_fd;
> > +   fd_tap.target_pid = pid;
> > +
> > +   if (eventfd_copy(dev, &fd_tap))
> > +   return -1;
> > +
> > +   ret = ioctl(fd_tap.source_fd, TUNGETIFF, &ifr);
> > +
> > +   if (close(fd_tap.source_fd) < 0)
> > +   RTE_LOG(ERR, VHOST_CONFIG,
> > +   "(%"PRIu64") fd close failed\n",
> > +   dev->device_fh);
> > +
> > +   if (ret >= 0) {
> > +   ifr_size = strnlen(ifr.ifr_name, sizeof(ifr.ifr_name));
> > +   size = ifr_size > sizeof(dev->ifname)?
> > +   sizeof(dev->ifname): ifr_size;
> > +
> > +   strncpy(dev->ifname, ifr.ifr_name, size);
> > +   } else
> > +   RTE_LOG(ERR, VHOST_CONFIG,
> > +   "(%"PRIu64") TUNGETIFF ioctl failed\n",
> > +   dev->device_fh);
> > +
> > +   return 0;
> > +}
> > +
> > +/*
> >   * Called from CUSE IOCTL: VHOST_NET_SET_BACKEND
> >   * To complete device initialisation when the virtio driver is loaded,
> >   * we are provided with a valid fd for a tap device (not used by us).
> > @@ -1026,8 +1070,10 @@ set_backend(struct vhost_device_ctx ctx, struct
> vhost_vring_file *file)
> >  */
> > if (!(dev->flags & VIRTIO_DEV_RUNNING)) {
> > if (((int)dev->virtqueue[VIRTIO_TXQ]->backend !=
> VIRTIO_DEV_STOPPED) &&
> > -   ((int)dev->virtqueue[VIRTIO_RXQ]->backend !=
> VIRTIO_DEV_STOPPED))
> > +   ((int)dev->virtqueue[VIRTIO_RXQ]->backend !=
> VIRTIO_DEV_STOPPED)) {
> > +   get_ifname(dev, file->fd, ctx.pid);
> > return notify_ops->new_device(dev);
> > +   }
> > /* Otherwise we remove it. */
> > } else
> > if (file->fd == VIRTIO_DEV_STOPPED)
> >
> 
> --
> Regards,
> Haifeng