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 >