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
>
