[dpdk-dev] Reshuffling of rte_mbuf structure.

[shesha Sreenivasamurthy (shesha)]

Is there a way where we can just define the fields that ought to be there in the mbuf structure, but the position and size is implementation dependent ? The application can provide "mbuf_impl.h" that contains mbuf_rte fields in the order that seems appropriate to application.

--
- Thanks
char * (*shesha) (uint64_t cache, uint8_t F00D)
{ return 0x0000C0DE; }

From: Matthew Hall <mhall at mhcomputing.net<mailto:mhall at mhcomputing.net>>
Date: Monday, November 2, 2015 at 4:21 PM
To: Thomas Monjalon <thomas.monjalon at 6wind.com<mailto:thomas.monjalon at 6wind.com>>
Cc: Cisco Employee <shesha at cisco.com<mailto:shesha at cisco.com>>, Arnon Warshavsky <arnon at qwilt.com<mailto:arnon at qwilt.com>>, "dev at dpdk.org<mailto:dev at dpdk.org>" <dev at dpdk.org<mailto:dev at dpdk.org>>
Subject: Re: [dpdk-dev] Reshuffling of rte_mbuf structure.

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.