[v8,6/6] lib/eventdev: use custom element size ring for event rings

Message ID 20200113172518.37815-7-honnappa.nagarahalli@arm.com
State Superseded
Headers show
Series
  • lib/ring: APIs to support custom element size
Related show

Commit Message

Honnappa Nagarahalli Jan. 13, 2020, 5:25 p.m.
Use custom element size ring APIs to replace event ring
implementation. This avoids code duplication.

Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>

Reviewed-by: Gavin Hu <gavin.hu@arm.com>

Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>

---
 lib/librte_eventdev/rte_event_ring.c | 147 ++-------------------------
 lib/librte_eventdev/rte_event_ring.h |  45 ++++----
 2 files changed, 24 insertions(+), 168 deletions(-)

-- 
2.17.1

Comments

Aaron Conole Jan. 14, 2020, 3:12 p.m. | #1
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

> Hi Aaron,

> I am not able to understand the error, looks like there is no

> particular error. Can you please take a look?


Gladly.  A number of the systems that were running the build stopped
their output for an unknown reason (looks like this was a 1-time
thing).  See the error:

  [2164/2165] Compiling C object 'app/te...st@@dpdk-test@exe/test_ring_perf.c.o'.

  No output has been received in the last 10m0s, this potentially
  indicates a stalled build or something wrong with the build itself.

My guess is some kind of infrastructure change happened during the
build?  Maybe compiling the test_ring_perf.c object has been pushed out
too far.  I've restarted one of the jobs to see if it will successfully
execute.  If so, it's just a fluke.

As for the fluke part, the intent is to enhance the robot to detect
these "error" conditions and issue a restart for the travis build
(rather than not report a valid state).  That's work TBD (but patches
are welcome - see https://github.com/orgcandman/pw-ci for all the bot
code).

> Thank you,

> Honnappa

>

> -----Original Message-----

> From: 0-day Robot <robot@bytheb.org>

> Sent: Monday, January 13, 2020 10:58 PM

> To: test-report@dpdk.org

> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; robot@bytheb.org

> Subject: || pw64572 lib/eventdev: use custom element size ring for event rings

>

> From: robot@bytheb.org

>

> Test-Label: travis-robot

> Test-Status:

> http://dpdk.org/patch/64572

>

> _Travis build: errored_

> Build URL: https://travis-ci.com/ovsrobot/dpdk/builds/144202958

> IMPORTANT NOTICE: The contents of this email and any attachments are

> confidential and may also be privileged. If you are not the intended

> recipient, please notify the sender immediately and do not disclose

> the contents to any other person, use it for any purpose, or store or

> copy the information in any medium. Thank you.

> IMPORTANT NOTICE: The contents of this email and any attachments are

> confidential and may also be privileged. If you are not the intended

> recipient, please notify the sender immediately and do not disclose

> the contents to any other person, use it for any purpose, or store or

> copy the information in any medium. Thank you.
Aaron Conole Jan. 14, 2020, 4:51 p.m. | #2
Aaron Conole <aconole@redhat.com> writes:

> Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

>

>> Hi Aaron,

>> I am not able to understand the error, looks like there is no

>> particular error. Can you please take a look?

>

> Gladly.  A number of the systems that were running the build stopped

> their output for an unknown reason (looks like this was a 1-time

> thing).  See the error:

>

>   [2164/2165] Compiling C object 'app/te...st@@dpdk-test@exe/test_ring_perf.c.o'.

>

>   No output has been received in the last 10m0s, this potentially

>   indicates a stalled build or something wrong with the build itself.


I see this continually happening (I've kicked it off a number of times).

This patch might need more investigation, since it's always failing when
building 2164/2165 object.

I'll note that it seems to be clang related, rather than gcc related.

> My guess is some kind of infrastructure change happened during the

> build?  Maybe compiling the test_ring_perf.c object has been pushed out

> too far.  I've restarted one of the jobs to see if it will successfully

> execute.  If so, it's just a fluke.

>

> As for the fluke part, the intent is to enhance the robot to detect

> these "error" conditions and issue a restart for the travis build

> (rather than not report a valid state).  That's work TBD (but patches

> are welcome - see https://github.com/orgcandman/pw-ci for all the bot

> code).

>

>> Thank you,

>> Honnappa

>>

>> -----Original Message-----

>> From: 0-day Robot <robot@bytheb.org>

>> Sent: Monday, January 13, 2020 10:58 PM

>> To: test-report@dpdk.org

>> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; robot@bytheb.org

>> Subject: || pw64572 lib/eventdev: use custom element size ring for event rings

>>

>> From: robot@bytheb.org

>>

>> Test-Label: travis-robot

>> Test-Status:

>> http://dpdk.org/patch/64572

>>

>> _Travis build: errored_

>> Build URL: https://travis-ci.com/ovsrobot/dpdk/builds/144202958

>> IMPORTANT NOTICE: The contents of this email and any attachments are

>> confidential and may also be privileged. If you are not the intended

>> recipient, please notify the sender immediately and do not disclose

>> the contents to any other person, use it for any purpose, or store or

>> copy the information in any medium. Thank you.

>> IMPORTANT NOTICE: The contents of this email and any attachments are

>> confidential and may also be privileged. If you are not the intended

>> recipient, please notify the sender immediately and do not disclose

>> the contents to any other person, use it for any purpose, or store or

>> copy the information in any medium. Thank you.
Honnappa Nagarahalli Jan. 14, 2020, 7:35 p.m. | #3
<snip>
> 

> Aaron Conole <aconole@redhat.com> writes:

> 

> > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

> >

> >> Hi Aaron,

> >> I am not able to understand the error, looks like there is no

> >> particular error. Can you please take a look?

> >

> > Gladly.  A number of the systems that were running the build stopped

> > their output for an unknown reason (looks like this was a 1-time

> > thing).  See the error:

> >

> >   [2164/2165] Compiling C object 'app/te...st@@dpdk-

> test@exe/test_ring_perf.c.o'.

> >

> >   No output has been received in the last 10m0s, this potentially

> >   indicates a stalled build or something wrong with the build itself.

> 

> I see this continually happening (I've kicked it off a number of times).

> 

> This patch might need more investigation, since it's always failing when

> building 2164/2165 object.

I compiled with clang-7. Compiler seems to hang while compiling test_ring.c

> 

> I'll note that it seems to be clang related, rather than gcc related.

> 

> > My guess is some kind of infrastructure change happened during the

> > build?  Maybe compiling the test_ring_perf.c object has been pushed

> > out too far.  I've restarted one of the jobs to see if it will

> > successfully execute.  If so, it's just a fluke.

> >

> > As for the fluke part, the intent is to enhance the robot to detect

> > these "error" conditions and issue a restart for the travis build

> > (rather than not report a valid state).  That's work TBD (but patches

> > are welcome - see https://github.com/orgcandman/pw-ci for all the bot

> > code).

> >

> >> Thank you,

> >> Honnappa

> >>

> >> -----Original Message-----

> >> From: 0-day Robot <robot@bytheb.org>

> >> Sent: Monday, January 13, 2020 10:58 PM

> >> To: test-report@dpdk.org

> >> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;

> >> robot@bytheb.org

> >> Subject: || pw64572 lib/eventdev: use custom element size ring for

> >> event rings

> >>

> >> From: robot@bytheb.org

> >>

> >> Test-Label: travis-robot

> >> Test-Status:

> >> http://dpdk.org/patch/64572

> >>

> >> _Travis build: errored_

> >> Build URL: https://travis-ci.com/ovsrobot/dpdk/builds/144202958
Aaron Conole Jan. 14, 2020, 8:44 p.m. | #4
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

> <snip>

>> 

>> Aaron Conole <aconole@redhat.com> writes:

>> 

>> > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

>> >

>> >> Hi Aaron,

>> >> I am not able to understand the error, looks like there is no

>> >> particular error. Can you please take a look?

>> >

>> > Gladly.  A number of the systems that were running the build stopped

>> > their output for an unknown reason (looks like this was a 1-time

>> > thing).  See the error:

>> >

>> >   [2164/2165] Compiling C object 'app/te...st@@dpdk-

>> test@exe/test_ring_perf.c.o'.

>> >

>> >   No output has been received in the last 10m0s, this potentially

>> >   indicates a stalled build or something wrong with the build itself.

>> 

>> I see this continually happening (I've kicked it off a number of times).

>> 

>> This patch might need more investigation, since it's always failing when

>> building 2164/2165 object.

> I compiled with clang-7. Compiler seems to hang while compiling test_ring.c


Cool.  Looks like a good catch, then :)

>> 

>> I'll note that it seems to be clang related, rather than gcc related.

>> 

>> > My guess is some kind of infrastructure change happened during the

>> > build?  Maybe compiling the test_ring_perf.c object has been pushed

>> > out too far.  I've restarted one of the jobs to see if it will

>> > successfully execute.  If so, it's just a fluke.

>> >

>> > As for the fluke part, the intent is to enhance the robot to detect

>> > these "error" conditions and issue a restart for the travis build

>> > (rather than not report a valid state).  That's work TBD (but patches

>> > are welcome - see https://github.com/orgcandman/pw-ci for all the bot

>> > code).

>> >

>> >> Thank you,

>> >> Honnappa

>> >>

>> >> -----Original Message-----

>> >> From: 0-day Robot <robot@bytheb.org>

>> >> Sent: Monday, January 13, 2020 10:58 PM

>> >> To: test-report@dpdk.org

>> >> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;

>> >> robot@bytheb.org

>> >> Subject: || pw64572 lib/eventdev: use custom element size ring for

>> >> event rings

>> >>

>> >> From: robot@bytheb.org

>> >>

>> >> Test-Label: travis-robot

>> >> Test-Status:

>> >> http://dpdk.org/patch/64572

>> >>

>> >> _Travis build: errored_

>> >> Build URL: https://travis-ci.com/ovsrobot/dpdk/builds/144202958
Honnappa Nagarahalli Jan. 15, 2020, 12:55 a.m. | #5
<snip>
> >>

> >> Aaron Conole <aconole@redhat.com> writes:

> >>

> >> > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

> >> >

> >> >> Hi Aaron,

> >> >> I am not able to understand the error, looks like there is no

> >> >> particular error. Can you please take a look?

> >> >

> >> > Gladly.  A number of the systems that were running the build

> >> > stopped their output for an unknown reason (looks like this was a

> >> > 1-time thing).  See the error:

> >> >

> >> >   [2164/2165] Compiling C object 'app/te...st@@dpdk-

> >> test@exe/test_ring_perf.c.o'.

> >> >

> >> >   No output has been received in the last 10m0s, this potentially

> >> >   indicates a stalled build or something wrong with the build itself.

> >>

> >> I see this continually happening (I've kicked it off a number of times).

> >>

> >> This patch might need more investigation, since it's always failing

> >> when building 2164/2165 object.

> > I compiled with clang-7. Compiler seems to hang while compiling

> > test_ring.c

> 

> Cool.  Looks like a good catch, then :)

Good test for Clang CI 😊

<snip>
Honnappa Nagarahalli Jan. 15, 2020, 4:43 a.m. | #6
<snip>
> >>

> >> Aaron Conole <aconole@redhat.com> writes:

> >>

> >> > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

> >> >

> >> >> Hi Aaron,

> >> >> I am not able to understand the error, looks like there is no

> >> >> particular error. Can you please take a look?

> >> >

> >> > Gladly.  A number of the systems that were running the build

> >> > stopped their output for an unknown reason (looks like this was a

> >> > 1-time thing).  See the error:

> >> >

> >> >   [2164/2165] Compiling C object 'app/te...st@@dpdk-

> >> test@exe/test_ring_perf.c.o'.

> >> >

> >> >   No output has been received in the last 10m0s, this potentially

> >> >   indicates a stalled build or something wrong with the build itself.

> >>

> >> I see this continually happening (I've kicked it off a number of times).

> >>

> >> This patch might need more investigation, since it's always failing

> >> when building 2164/2165 object.

> > I compiled with clang-7. Compiler seems to hang while compiling

> > test_ring.c

> 

> Cool.  Looks like a good catch, then :)

Update:
x86 - compilation succeeds, but take a long time - ~1hr.
On 2 different Arm platforms - compilation succeeds in normal amount of time.
Does anyone have any experience dealing with this kind of issue?

<snip>
Honnappa Nagarahalli Jan. 15, 2020, 5:05 a.m. | #7
<snip>
> > >>

> > >> Aaron Conole <aconole@redhat.com> writes:

> > >>

> > >> > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

> > >> >

> > >> >> Hi Aaron,

> > >> >> I am not able to understand the error, looks like there is no

> > >> >> particular error. Can you please take a look?

> > >> >

> > >> > Gladly.  A number of the systems that were running the build

> > >> > stopped their output for an unknown reason (looks like this was a

> > >> > 1-time thing).  See the error:

> > >> >

> > >> >   [2164/2165] Compiling C object 'app/te...st@@dpdk-

> > >> test@exe/test_ring_perf.c.o'.

> > >> >

> > >> >   No output has been received in the last 10m0s, this potentially

> > >> >   indicates a stalled build or something wrong with the build itself.

> > >>

> > >> I see this continually happening (I've kicked it off a number of times).

> > >>

> > >> This patch might need more investigation, since it's always failing

> > >> when building 2164/2165 object.

> > > I compiled with clang-7. Compiler seems to hang while compiling

> > > test_ring.c

> >

> > Cool.  Looks like a good catch, then :)

> Update:

> x86 - compilation succeeds, but take a long time - ~1hr.

> On 2 different Arm platforms - compilation succeeds in normal amount of

> time.

> Does anyone have any experience dealing with this kind of issue?

> 

I ran this on another x86 server - this patch takes ~8mns. The master (without this patch) takes ~1.02mns.

> <snip>
Aaron Conole Jan. 15, 2020, 6:22 p.m. | #8
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

> <snip>

>> > >>

>> > >> Aaron Conole <aconole@redhat.com> writes:

>> > >>

>> > >> > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

>> > >> >

>> > >> >> Hi Aaron,

>> > >> >> I am not able to understand the error, looks like there is no

>> > >> >> particular error. Can you please take a look?

>> > >> >

>> > >> > Gladly.  A number of the systems that were running the build

>> > >> > stopped their output for an unknown reason (looks like this was a

>> > >> > 1-time thing).  See the error:

>> > >> >

>> > >> >   [2164/2165] Compiling C object 'app/te...st@@dpdk-

>> > >> test@exe/test_ring_perf.c.o'.

>> > >> >

>> > >> >   No output has been received in the last 10m0s, this potentially

>> > >> >   indicates a stalled build or something wrong with the build itself.

>> > >>

>> > >> I see this continually happening (I've kicked it off a number of times).

>> > >>

>> > >> This patch might need more investigation, since it's always failing

>> > >> when building 2164/2165 object.

>> > > I compiled with clang-7. Compiler seems to hang while compiling

>> > > test_ring.c

>> >

>> > Cool.  Looks like a good catch, then :)

>> Update:

>> x86 - compilation succeeds, but take a long time - ~1hr.

>> On 2 different Arm platforms - compilation succeeds in normal amount of

>> time.

>> Does anyone have any experience dealing with this kind of issue?

>> 

> I ran this on another x86 server - this patch takes ~8mns. The master

> (without this patch) takes ~1.02mns.


It doesn't reproduce with clang-8.

>> <snip>
Honnappa Nagarahalli Jan. 15, 2020, 6:38 p.m. | #9
<snip>
> >> > >>

> >> > >> Aaron Conole <aconole@redhat.com> writes:

> >> > >>

> >> > >> > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

> >> > >> >

> >> > >> >> Hi Aaron,

> >> > >> >> I am not able to understand the error, looks like there is no

> >> > >> >> particular error. Can you please take a look?

> >> > >> >

> >> > >> > Gladly.  A number of the systems that were running the build

> >> > >> > stopped their output for an unknown reason (looks like this

> >> > >> > was a 1-time thing).  See the error:

> >> > >> >

> >> > >> >   [2164/2165] Compiling C object 'app/te...st@@dpdk-

> >> > >> test@exe/test_ring_perf.c.o'.

> >> > >> >

> >> > >> >   No output has been received in the last 10m0s, this potentially

> >> > >> >   indicates a stalled build or something wrong with the build itself.

> >> > >>

> >> > >> I see this continually happening (I've kicked it off a number of times).

> >> > >>

> >> > >> This patch might need more investigation, since it's always

> >> > >> failing when building 2164/2165 object.

> >> > > I compiled with clang-7. Compiler seems to hang while compiling

> >> > > test_ring.c

> >> >

> >> > Cool.  Looks like a good catch, then :)

> >> Update:

> >> x86 - compilation succeeds, but take a long time - ~1hr.

> >> On 2 different Arm platforms - compilation succeeds in normal amount

> >> of time.

> >> Does anyone have any experience dealing with this kind of issue?

> >>

> > I ran this on another x86 server - this patch takes ~8mns. The master

> > (without this patch) takes ~1.02mns.

> 

> It doesn't reproduce with clang-8.

Ok, do you want to update the Travis CI and re-run?

> 

> >> <snip>
Honnappa Nagarahalli Jan. 16, 2020, 5:27 a.m. | #10
<snip>
> > >> > >>

> > >> > >> Aaron Conole <aconole@redhat.com> writes:

> > >> > >>

> > >> > >> > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

> > >> > >> >

> > >> > >> >> Hi Aaron,

> > >> > >> >> I am not able to understand the error, looks like there is

> > >> > >> >> no particular error. Can you please take a look?

> > >> > >> >

> > >> > >> > Gladly.  A number of the systems that were running the build

> > >> > >> > stopped their output for an unknown reason (looks like this

> > >> > >> > was a 1-time thing).  See the error:

> > >> > >> >

> > >> > >> >   [2164/2165] Compiling C object 'app/te...st@@dpdk-

> > >> > >> test@exe/test_ring_perf.c.o'.

> > >> > >> >

> > >> > >> >   No output has been received in the last 10m0s, this potentially

> > >> > >> >   indicates a stalled build or something wrong with the build itself.

> > >> > >>

> > >> > >> I see this continually happening (I've kicked it off a number of times).

> > >> > >>

> > >> > >> This patch might need more investigation, since it's always

> > >> > >> failing when building 2164/2165 object.

> > >> > > I compiled with clang-7. Compiler seems to hang while compiling

> > >> > > test_ring.c

> > >> >

> > >> > Cool.  Looks like a good catch, then :)

> > >> Update:

> > >> x86 - compilation succeeds, but take a long time - ~1hr.

> > >> On 2 different Arm platforms - compilation succeeds in normal

> > >> amount of time.

> > >> Does anyone have any experience dealing with this kind of issue?

> > >>

> > > I ran this on another x86 server - this patch takes ~8mns. The

> > > master (without this patch) takes ~1.02mns.

> >

> > It doesn't reproduce with clang-8.

> Ok, do you want to update the Travis CI and re-run?

I isolated the compilation issue to one of the test cases. It was a large function and I have split it into smaller functions. The compilation time reduces significantly. I have submitted a new version.

> 

> >

> > >> <snip>

Patch

diff --git a/lib/librte_eventdev/rte_event_ring.c b/lib/librte_eventdev/rte_event_ring.c
index 50190de01..d27e23901 100644
--- a/lib/librte_eventdev/rte_event_ring.c
+++ b/lib/librte_eventdev/rte_event_ring.c
@@ -1,5 +1,6 @@ 
 /* SPDX-License-Identifier: BSD-3-Clause
  * Copyright(c) 2017 Intel Corporation
+ * Copyright(c) 2019 Arm Limited
  */
 
 #include <sys/queue.h>
@@ -11,13 +12,6 @@ 
 #include <rte_eal_memconfig.h>
 #include "rte_event_ring.h"
 
-TAILQ_HEAD(rte_event_ring_list, rte_tailq_entry);
-
-static struct rte_tailq_elem rte_event_ring_tailq = {
-	.name = RTE_TAILQ_EVENT_RING_NAME,
-};
-EAL_REGISTER_TAILQ(rte_event_ring_tailq)
-
 int
 rte_event_ring_init(struct rte_event_ring *r, const char *name,
 	unsigned int count, unsigned int flags)
@@ -35,150 +29,21 @@  struct rte_event_ring *
 rte_event_ring_create(const char *name, unsigned int count, int socket_id,
 		unsigned int flags)
 {
-	char mz_name[RTE_MEMZONE_NAMESIZE];
-	struct rte_event_ring *r;
-	struct rte_tailq_entry *te;
-	const struct rte_memzone *mz;
-	ssize_t ring_size;
-	int mz_flags = 0;
-	struct rte_event_ring_list *ring_list = NULL;
-	const unsigned int requested_count = count;
-	int ret;
-
-	ring_list = RTE_TAILQ_CAST(rte_event_ring_tailq.head,
-		rte_event_ring_list);
-
-	/* for an exact size ring, round up from count to a power of two */
-	if (flags & RING_F_EXACT_SZ)
-		count = rte_align32pow2(count + 1);
-	else if (!rte_is_power_of_2(count)) {
-		rte_errno = EINVAL;
-		return NULL;
-	}
-
-	ring_size = sizeof(*r) + (count * sizeof(struct rte_event));
-
-	ret = snprintf(mz_name, sizeof(mz_name), "%s%s",
-		RTE_RING_MZ_PREFIX, name);
-	if (ret < 0 || ret >= (int)sizeof(mz_name)) {
-		rte_errno = ENAMETOOLONG;
-		return NULL;
-	}
-
-	te = rte_zmalloc("RING_TAILQ_ENTRY", sizeof(*te), 0);
-	if (te == NULL) {
-		RTE_LOG(ERR, RING, "Cannot reserve memory for tailq\n");
-		rte_errno = ENOMEM;
-		return NULL;
-	}
-
-	rte_mcfg_tailq_write_lock();
-
-	/*
-	 * reserve a memory zone for this ring. If we can't get rte_config or
-	 * we are secondary process, the memzone_reserve function will set
-	 * rte_errno for us appropriately - hence no check in this this function
-	 */
-	mz = rte_memzone_reserve(mz_name, ring_size, socket_id, mz_flags);
-	if (mz != NULL) {
-		r = mz->addr;
-		/* Check return value in case rte_ring_init() fails on size */
-		int err = rte_event_ring_init(r, name, requested_count, flags);
-		if (err) {
-			RTE_LOG(ERR, RING, "Ring init failed\n");
-			if (rte_memzone_free(mz) != 0)
-				RTE_LOG(ERR, RING, "Cannot free memzone\n");
-			rte_free(te);
-			rte_mcfg_tailq_write_unlock();
-			return NULL;
-		}
-
-		te->data = (void *) r;
-		r->r.memzone = mz;
-
-		TAILQ_INSERT_TAIL(ring_list, te, next);
-	} else {
-		r = NULL;
-		RTE_LOG(ERR, RING, "Cannot reserve memory\n");
-		rte_free(te);
-	}
-	rte_mcfg_tailq_write_unlock();
-
-	return r;
+	return (struct rte_event_ring *)rte_ring_create_elem(name,
+						sizeof(struct rte_event),
+						count, socket_id, flags);
 }
 
 
 struct rte_event_ring *
 rte_event_ring_lookup(const char *name)
 {
-	struct rte_tailq_entry *te;
-	struct rte_event_ring *r = NULL;
-	struct rte_event_ring_list *ring_list;
-
-	ring_list = RTE_TAILQ_CAST(rte_event_ring_tailq.head,
-			rte_event_ring_list);
-
-	rte_mcfg_tailq_read_lock();
-
-	TAILQ_FOREACH(te, ring_list, next) {
-		r = (struct rte_event_ring *) te->data;
-		if (strncmp(name, r->r.name, RTE_RING_NAMESIZE) == 0)
-			break;
-	}
-
-	rte_mcfg_tailq_read_unlock();
-
-	if (te == NULL) {
-		rte_errno = ENOENT;
-		return NULL;
-	}
-
-	return r;
+	return (struct rte_event_ring *)rte_ring_lookup(name);
 }
 
 /* free the ring */
 void
 rte_event_ring_free(struct rte_event_ring *r)
 {
-	struct rte_event_ring_list *ring_list = NULL;
-	struct rte_tailq_entry *te;
-
-	if (r == NULL)
-		return;
-
-	/*
-	 * Ring was not created with rte_event_ring_create,
-	 * therefore, there is no memzone to free.
-	 */
-	if (r->r.memzone == NULL) {
-		RTE_LOG(ERR, RING,
-			"Cannot free ring (not created with rte_event_ring_create()");
-		return;
-	}
-
-	if (rte_memzone_free(r->r.memzone) != 0) {
-		RTE_LOG(ERR, RING, "Cannot free memory\n");
-		return;
-	}
-
-	ring_list = RTE_TAILQ_CAST(rte_event_ring_tailq.head,
-			rte_event_ring_list);
-	rte_mcfg_tailq_write_lock();
-
-	/* find out tailq entry */
-	TAILQ_FOREACH(te, ring_list, next) {
-		if (te->data == (void *) r)
-			break;
-	}
-
-	if (te == NULL) {
-		rte_mcfg_tailq_write_unlock();
-		return;
-	}
-
-	TAILQ_REMOVE(ring_list, te, next);
-
-	rte_mcfg_tailq_write_unlock();
-
-	rte_free(te);
+	rte_ring_free((struct rte_ring *)r);
 }
diff --git a/lib/librte_eventdev/rte_event_ring.h b/lib/librte_eventdev/rte_event_ring.h
index 827a3209e..c0861b0ec 100644
--- a/lib/librte_eventdev/rte_event_ring.h
+++ b/lib/librte_eventdev/rte_event_ring.h
@@ -1,5 +1,6 @@ 
 /* SPDX-License-Identifier: BSD-3-Clause
  * Copyright(c) 2016-2017 Intel Corporation
+ * Copyright(c) 2019 Arm Limited
  */
 
 /**
@@ -19,6 +20,7 @@ 
 #include <rte_memory.h>
 #include <rte_malloc.h>
 #include <rte_ring.h>
+#include <rte_ring_elem.h>
 #include "rte_eventdev.h"
 
 #define RTE_TAILQ_EVENT_RING_NAME "RTE_EVENT_RING"
@@ -88,22 +90,17 @@  rte_event_ring_enqueue_burst(struct rte_event_ring *r,
 		const struct rte_event *events,
 		unsigned int n, uint16_t *free_space)
 {
-	uint32_t prod_head, prod_next;
-	uint32_t free_entries;
+	unsigned int num;
+	uint32_t space;
 
-	n = __rte_ring_move_prod_head(&r->r, r->r.prod.single, n,
-			RTE_RING_QUEUE_VARIABLE,
-			&prod_head, &prod_next, &free_entries);
-	if (n == 0)
-		goto end;
+	num = rte_ring_enqueue_burst_elem(&r->r, events,
+				sizeof(struct rte_event), n,
+				&space);
 
-	ENQUEUE_PTRS(&r->r, &r[1], prod_head, events, n, struct rte_event);
-
-	update_tail(&r->r.prod, prod_head, prod_next, r->r.prod.single, 1);
-end:
 	if (free_space != NULL)
-		*free_space = free_entries - n;
-	return n;
+		*free_space = space;
+
+	return num;
 }
 
 /**
@@ -129,23 +126,17 @@  rte_event_ring_dequeue_burst(struct rte_event_ring *r,
 		struct rte_event *events,
 		unsigned int n, uint16_t *available)
 {
-	uint32_t cons_head, cons_next;
-	uint32_t entries;
-
-	n = __rte_ring_move_cons_head(&r->r, r->r.cons.single, n,
-			RTE_RING_QUEUE_VARIABLE,
-			&cons_head, &cons_next, &entries);
-	if (n == 0)
-		goto end;
+	unsigned int num;
+	uint32_t remaining;
 
-	DEQUEUE_PTRS(&r->r, &r[1], cons_head, events, n, struct rte_event);
+	num = rte_ring_dequeue_burst_elem(&r->r, events,
+				sizeof(struct rte_event), n,
+				&remaining);
 
-	update_tail(&r->r.cons, cons_head, cons_next, r->r.cons.single, 0);
-
-end:
 	if (available != NULL)
-		*available = entries - n;
-	return n;
+		*available = remaining;
+
+	return num;
 }
 
 /*