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

[Stephen Hemminger <stephen@networkplumber.org>]

On Wed, 28 Sep 2022 14:52:47 +0200
Olivier Matz <olivier.matz@6wind.com> wrote:

> On Wed, Sep 28, 2022 at 09:24:51AM +0200, Thomas Monjalon wrote:
> > 21/09/2022 15:56, Shijith Thotton:  
> > > 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.