> >On Thu, Jun 30, 2022 at 05:55:21PM +0100, Bruce Richardson wrote: >> On Thu, Jun 30, 2022 at 09:55:16PM +0530, Shijith Thotton wrote: >> > If all devices are configured to run in IOVA mode as VA, physical >> > address field of mbuf (buf_iova) won't be used. 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> >> > --- >> I disagree with this patch. The mbuf should always record the iova of the >> buffer directly, rather than forcing the drivers to query the EAL mode. >> This will likely also break all vector drivers right now, as they are >> sensitive to the mbuf layout and the position of the IOVA address in the >> buffer. > Hi Bruce,
The IOVA check should have been bus specific, instead of eal. The bus IOVA mode will be VA, only if all devices on the bus has the flag RTE_PCI_DRV_NEED_IOVA_AS_VA. It was our thought process, but used wrong API for the check. It should have avoided the issue which you mentioned above. >I have the same opinion than Stephen and Bruce. This field is widely used >in DPDK, I don't think it is a good idea to disable it if some conditions >are met. Hi Olivier, I was under the assumption, buf_iova won't be used directly by the application (only through wrapper). So that wrappers can check ol_flags before setting buf_iova.
