[PATCH v4 01/18] mbuf: deprecate GCC marker in rte mbuf struct

[Tyler Retzlaff]

On Tue, Feb 20, 2024 at 08:16:23PM +0100, Thomas Monjalon wrote:
> 20/02/2024 18:53, Thomas Monjalon:
> > 20/02/2024 18:20, Tyler Retzlaff:
> > > On Sun, Feb 18, 2024 at 01:39:52PM +0100, Thomas Monjalon wrote:
> > > > 15/02/2024 07:21, Tyler Retzlaff:
> > > > > Provide a macro that allows conditional expansion of RTE_MARKER fields
> > > > > to empty to allow rte_mbuf to be used with MSVC. It is proposed that
> > > > > we announce the fields to be __rte_deprecated (currently disabled).
> > > > > 
> > > > > Introduce C11 anonymous unions to permit aliasing of well-known
> > > > > offsets by name into the rte_mbuf structure by a *new* name and to
> > > > > provide padding for cache alignment.
> > [...]
> > > > >  struct rte_mbuf {
> > > > > -	RTE_MARKER cacheline0;
> > > > > -
> > > > > -	void *buf_addr;           /**< Virtual address of segment buffer. */
> > > > > +	__rte_marker(RTE_MARKER, cacheline0);
> > > > > +	union {
> > > > > +		char mbuf_cacheline0[RTE_CACHE_LINE_MIN_SIZE];
> > > > > +		__extension__
> > > > > +		struct {
> > > > > +			void *buf_addr;           /**< Virtual address of segment buffer. 
> > > > 
> > > > I think it is ugly.
> > > > 
> > > > Changing mbuf API is a serious issue.
> > > 
> > > agreed, do you have an alternate proposal to solve problem?
> > 
> > The best would be that MSVC supports a kind of struct marker.
> 
> After more thoughts, it's OK to break API for mbuf markers.
> There are 2 kind of markers in mbuf:
> 	1/ cacheline markers used only in rte_mbuf_prefetch_part functions
> 	2/ rearm_data and rx_descriptor_fields1 which are offsets used by drivers
> The cacheline markers can be removed and offset calculated in prefetch functions.
> The second type of markers are intended to be used by drivers only,
> so there is not API compatibility concern.
> Instead of complicated unions, I propose to replace them with inline functions
> which return the offset in the same type as the markers.
> 
> As RTE_MARKER macros rely on a non-standard C feature,
> I propose to mark them as non-recommended,
> and stop using them in DPDK code.
> We can keep them for compatibility and drop them when compiling with MSVC.
> 
> Some markers are used in crypto structures for cachelines,
> we can probably drop them easily, they look unused.
> 
> The last thing to handle is cacheline padding.
> It can be done on the first field of the next cacheline,
> instead of using a zero-sized marker for padding.
> 
> Problem solved? Let's get rid of these markers?

certainly simplifies things, i don't object i'll submit a new revision
with the suggestions outlined above.

thanks Thomas
>