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

[Matthew Hall <mhall@mhcomputing.net>]

On Tue, Nov 03, 2015 at 11:44:22AM +0000, Zoltan Kiss wrote:
> 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.

If the RX path is the cause of most of the issues, then it seems like we need 
to make some diagrams and a description of how this code works, so we could 
crowd-source the best proposed performance and cleanliness improvements.

Trying to solve this problem one little hack at a time isn't going to achieve 
the pretty demanding performance and flexibility constraints on the code.

Do we have some kind of plans to do bounties, specific wiki pages on known 
design problems, Google Summer of Code, or some other kind of process for 
longer-term architectural improvements?

Also, in this instance it seems like it might be wise to outsource some 
black-magic like these vector instructions, to some of the pre-optimized 
cleaner alternatives like rte_memcpy.

Matthew.