[dpdk-dev] [PATCH 0/3] ring clean up

[Feifei Wang]

> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev at intel.com>
> Sent: 2020年7月9日 1:06
> To: David Marchand <david.marchand at redhat.com>; Feifei Wang
> <Feifei.Wang2 at arm.com>
> Cc: dev <dev at dpdk.org>; nd <nd at arm.com>
> Subject: RE: [dpdk-dev] [PATCH 0/3] ring clean up
> 
> > On Fri, Jul 3, 2020 at 12:27 PM Feifei Wang <feifei.wang2 at arm.com> wrote:
> > >
> > > Do some work for ring refactoring, which includes:
> > > 1. remove experimental tags
> > > 2. use element APIs to implement legacy APIs
> >
> > This series triggers unit test failures.
> > https://travis-ci.com/github/ovsrobot/dpdk/builds/174196115
> >
> > https://travis-ci.com/github/ovsrobot/dpdk/jobs/357314387#L1092
> >
> > In my env:
> >
> > test_refcnt_slave started at lcore 22
> > test_refcnt_slave started at lcore 23
> > test_refcnt_slave started at lcore 24
> > test_refcnt_slave started at lcore 25
> > test_refcnt_slave started at lcore 26
> > test_refcnt_slave started at lcore 27
> > test_refcnt_master started at lcore 1
> >
> > Thread 6 "lcore-slave-4" received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7ffff4723400 (LWP 374679)]
> > 0x00000000007e29d0 in rte_pktmbuf_free (m=0xffff000100010000) at
> > ../../dpdk/lib/librte_mbuf/rte_mbuf.h:1407
> > 1407            m_next = m->next;
> > Missing separate debuginfos, use: dnf debuginfo-install
> > dbus-libs-1.12.18-1.fc31.x86_64 elfutils-libelf-0.179-2.fc31.x86_64
> > jansson-2.12-4.fc31.x86_64 libbpf-0.0.7-1.fc31.x86_64
> > libbsd-0.9.1-4.fc31.x86_64 libfdt-1.6.0-1.fc31.x86_64
> > libgcc-9.3.1-2.fc31.x86_64 libgcrypt-1.8.5-1.fc31.x86_64
> > libnl3-3.5.0-1.fc31.x86_64 libpcap-1.9.1-2.fc31.x86_64
> > lz4-libs-1.9.1-1.fc31.x86_64 numactl-libs-2.0.12-3.fc31.x86_64
> > openssl-libs-1.1.1g-1.fc31.x86_64 systemd-libs-243.8-1.fc31.x86_64
> > xz-libs-5.2.5-1.fc31.x86_64 zlib-1.2.11-20.fc31.x86_64
> > (gdb) bt
> > #0  0x00000000007e29d0 in rte_pktmbuf_free (m=0xffff000100010000) at
> > ../../dpdk/lib/librte_mbuf/rte_mbuf.h:1407
> > #1  test_refcnt_slave (arg=0x17f7e3940) at
> > ../../dpdk/app/test/test_mbuf.c:1016
> > #2  0x0000000000446a89 in eal_thread_loop (arg=<optimized out>) at
> > ../../dpdk/lib/librte_eal/linux/eal_thread.c:127
> > #3  0x00007ffff709c4e2 in start_thread () from
> > /usr/lib64/libpthread.so.0
> > #4  0x00007ffff6fc96a3 in clone () from /usr/lib64/libc.so.6
> >
> 
> 
Hi, Konstantin

Thanks very much for your effort.
We are in the process of solving this problem and modify the same part. Until now, the tested result is OK.
Currently, we are conducting internal testing. After confirming it is fully secure, the new version will be sent to the community as soon as possible.

Thanks again
Feifei
> Ah, yes indeed there is problem within single enqueue.
> It should be:
> 
> diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h index
> 2a2190bfc..da17ed6d7 100644
> --- a/lib/librte_ring/rte_ring.h
> +++ b/lib/librte_ring/rte_ring.h
> @@ -284,7 +284,7 @@ rte_ring_enqueue_bulk(struct rte_ring *r, void *
> const *obj_table,  static __rte_always_inline int
> rte_ring_mp_enqueue(struct rte_ring *r, void *obj)  {
> -       return rte_ring_mp_enqueue_elem(r, obj, sizeof(void *));
> +       return rte_ring_mp_enqueue_elem(r, &obj, sizeof(void *));
>  }
> 
>  /**
> @@ -301,7 +301,7 @@ rte_ring_mp_enqueue(struct rte_ring *r, void *obj)
> static __rte_always_inline int  rte_ring_sp_enqueue(struct rte_ring *r, void
> *obj)  {
> -       return rte_ring_sp_enqueue_elem(r, obj, sizeof(void *));
> +       return rte_ring_sp_enqueue_elem(r, &obj, sizeof(void *));
>  }
> 
>  /**
> @@ -322,7 +322,7 @@ rte_ring_sp_enqueue(struct rte_ring *r, void *obj)
> static __rte_always_inline int  rte_ring_enqueue(struct rte_ring *r, void *obj)
> {
> -       return rte_ring_enqueue_elem(r, obj, sizeof(void *));
> +       return rte_ring_enqueue_elem(r, &obj, sizeof(void *));
>  }
> 
>  /**