> From: Shijith Thotton [mailto:sthot...@marvell.com] > Sent: Friday, 1 July 2022 14.25 > > >> If all devices are configured to run in IOVA mode as VA, physical > >> address field of mbuf (buf_iova) won't be used.
Will some of the hardware vendors please comment on this: Has IOVA VA mode become common over time, or is it still an exotic bleeding edge feature? If it has become common, we should let DPDK evolve accordingly, and consider PA (non-VA) mode legacy, treating it as such. Don't get stuck in the past. > >> In such cases, > buf_iova > >> space is free to use as a dynamic field. So a new dynamic field > member > >> (dynfield2) is added in mbuf structure to make use of that space. > >> > >> A new mbuf flag RTE_MBUF_F_DYNFIELD2 is introduced to help identify > the > >> mbuf that can use dynfield2. > >> > >> Signed-off-by: Shijith Thotton <sthot...@marvell.com> > > > > This seems like a complex and potentially error prone way to do this. Perhaps this optimization should be a compile time option instead? > > What is the use case? > > > > PCI drivers with the flag RTE_PCI_DRV_NEED_IOVA_AS_VA only works in > IOVA mode as > VA. buf_iova field of mbuf is not used by those PMDs and can be used as > a > dynamic area to save space. > > > How much of a performance gain? > > No change in performance. Freeing up 8 bytes in the first mbuf cache line is a major improvement! This could provide a significant performance gain for some applications, by moving private/dynamic mbuf fields from the second to the first cache line, thus avoiding to write to the second cache line in the application's first pipeline stage.
