[EXT] Re: [PATCH] mbuf: add mbuf physical address field to dynamic field
Shijith Thotton
sthotton at marvell.com
Fri Jul 1 14:01:40 CEST 2022
>
>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 <sthotton at 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.
More information about the dev
mailing list