[dpdk-dev] [RFC PATCH 00/11] generalise rte_ring to allow different datatypes

[Bruce Richardson]

The rte_ring library in DPDK provides an excellent high-performance
mechanism which can be used for passing pointers between cores and
for other tasks such as buffering. However, it does have a number
of limitations:

* type information of pointers is lost, as it works with void pointers
* typecasting is needed when using enqueue/dequeue burst functions,
  since arrays of other types cannot be automatically cast to void **
* the data to be passed through the ring itself must be no bigger than
  a pointer

While the first two limitations are an inconvenience, the final one is
one that can prevent use of rte_rings in cases where their functionality
is needed. The use-case which has inspired the patchset is that of
eventdev. When working with rte_events, each event is a 16-byte structure
consisting of a pointer and some metadata e.g. priority and type. For
these events, what is passed around between cores is not pointers to
events, but the events themselves. This makes existing rings unsuitable
for use by applications working with rte_events, and also for use
internally inside any software implementation of an eventdev.

For rings to handle events or other similarly sized structures, e.g.
NIC descriptors, etc., we then have two options - duplicate rte_ring
code to create new ring implementations for each of those types, or
generalise the existing code using macros so that the data type handled
by each rings is a compile time paramter. This patchset takes the latter
approach, and once applied would allow us to add an rte_event_ring type
to DPDK using a header file containing:

#define RING_TYPE struct rte_event
#define RING_TYPE_NAME rte_event
#include <rte_typed_ring.h>
#undef RING_TYPE_NAME
#undef RING_TYPE

[NOTE: the event_ring is not defined in this set, since it depends on
the eventdev implementation not present in the main tree]

If we want to elimiate some of the typecasting on our code when enqueuing
and dequeuing mbuf pointers, an rte_mbuf_ring type can be similarly
created using the same number of lines of code.

The downside of this generalisation is that the code for the rings now
has far more use of macros in it. However, I do not feel that overall
readability suffers much from this change, the since the changes are
pretty much just search-replace onces. There should also be no ABI
compatibility issues with this change, since the existing rte_ring
structures remain the same.

Bruce Richardson (11):
  ring: add new typed ring header file
  test: add new test file for typed rings
  ring: add ring management functions to typed ring header
  ring: make ring tailq variable public
  ring: add user-specified typing to typed rings
  ring: use existing power-of-2 function
  ring: allow multiple typed rings in the same unit
  app/pdump: remove duplicate macro definition
  ring: make existing rings reuse the typed ring definitions
  ring: reuse typed rings management functions
  ring: reuse typed ring enqueue and dequeue functions

 app/pdump/main.c                     |    1 -
 app/test/Makefile                    |    1 +
 app/test/test_typed_ring.c           |  156 ++++
 lib/librte_ring/Makefile             |    1 +
 lib/librte_ring/rte_ring.c           |  246 +-----
 lib/librte_ring/rte_ring.h           |  563 +-----------
 lib/librte_ring/rte_ring_version.map |    7 +
 lib/librte_ring/rte_typed_ring.h     | 1570 ++++++++++++++++++++++++++++++++++
 8 files changed, 1758 insertions(+), 787 deletions(-)
 create mode 100644 app/test/test_typed_ring.c
 create mode 100644 lib/librte_ring/rte_typed_ring.h

-- 
2.9.3