[dpdk-dev] Reshuffling of rte_mbuf structure.

[Matthew Hall]

On Mon, Nov 02, 2015 at 11:51:23PM +0100, Thomas Monjalon wrote:
> But it is simpler to say that having an API depending of some options
> is a "no-design" which could seriously slow down the DPDK adoption.

What about something similar to how Java JNI works? It needed to support 
multiple Java JRE / JDK brands, implementations etc. Upon initialization, a 
function pointer array is created, and specific slots are filled with pointers 
to the real implementation of some native API functions you can call from 
inside your library to perform operations.

In the DPDK case, we need flexible data instead of flexible function 
implementations.

To do this there would be some pointer slots in the mbuf that are are filled 
with pointers to metadata for required DPDK features. The data could be placed 
in the following cachelines, using some reserved tailroom between the mbuf 
control block and the packet data block. Then the prefetch could be set up to 
prefetch only the used parts of the tailroom at any given point, to prevent 
unwanted slowdowns.

Matthew.