Re: [dpdk-dev] Reshuffling of rte_mbuf structure.

[Zoltan Kiss <zoltan.kiss@linaro.org>]

Also, there could be places in the code where we change a set of 
continuous fields in the mbuf. E.g. ixgbe vector pmd receive function 
takes advantage of 128 bit vector registers and fill out 
rx_descriptor_fields1 with one instruction. But I guess there are other 
places too, and they are really hard to find with code analysis. A 
change in the mbuf structure would probably bring a plethora of nasty 
bugs due to this.

On 03/11/15 10:20, Bruce Richardson wrote:
> On Mon, Nov 02, 2015 at 07:21:17PM -0500, Matthew Hall wrote:
>> 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.
>
> The trouble is that a lot of the metadata comes from the receive descriptor on
> the RX code path, which is extremely sensitive to cache line usage. This is why
> in the 1.8 changes to the mbuf, the data used by the RX code paths were all put
> on the first cacheline.
>
> /Bruce
>