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?
