RE: [EXT] Re: [PATCH v3 2/5] mbuf: add second dynamic field member for VA only build

[Shijith Thotton <sthotton@marvell.com>]

>> > > mbuf physical address field is not used in builds which only uses VA. It
>> > > is used to expand the dynamic field area.
>> > >
>> > > Signed-off-by: Shijith Thotton <sthotton@marvell.com>
>> >
>> > We cannot condition the use of the dynamic field.
>> > I think it is enough justification to reject this patch.
>>
>> I don't think it is an issue.
>>
>> > And about adding a compilation option for IOVA in the first patch of this series,
>> > I think it is not the direction the majority wants DPDK to go.
>> > We tend to avoid compilation options.
>>
>> In general, I agree that we don't want to have many custom compile-time
>options,
>> especially if they impact ABI. It has several issues that have already been
>> widely discussed.
>>
>> However, in this specific case, we can suppose that removing buf_iova is a
>> long-term goal (in years). Having this compile-time option is a way to test this
>> approach, and progressively prepare the drivers to support it. Then, in few
>> years (if we are still convinced), we may announce an abi breakage and switch to
>> this new mode by default.
>
>Since field is invalid if compile option is set,
>shouldn't the field be inside an #ifdef so that if a driver or application
>was to make the mistake of using that directly, it would fail at compile
>time instead of runtime.
>
>Leaving booby traps for applications and drivers is bad design.
 
Will move to using #ifdef in v4.