+to: Thomas
> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> Sent: Saturday, 24 February 2024 09.22
>
> RTE_MARKER typedefs are a GCC extension unsupported by MSVC. This series
> hides the markers when building with MSVC and updates libraries and
> drivers to access compatibly typed pointers to the rte_mbuf struct
> offsets.
>
> This series, does the following.
>
> Introduces a new macro __rte_marker(type, name) which is used to
> conditionally expand RTE_MARKER fields empty when building with GCC.
Important typo: GCC -> MSVC.
Correct me if I'm wrong: When building with MSVC, the RTE_MARKER fields don't
exist at all.
>
> Updates existing inline functions accessing cacheline{0,1} markers in
> the rte_mbuf struct to stop using the markers and instead uses the mbuf
> fields directly.
>
> Introduces 2 new inline functions to allow drivers to access rearm_data
> and rx_descriptor_fields1 descriptors without using the RTE_MARKER
> fields.
>
> Updates all drivers to use the new inline rte_mbuf struct accessors for
> rearm_data and rx_descriptor_fields1.
>
> Any previous Acks on the series are considered to be reset due to amount
> of change.
>
> v5:
> * update existing cacheline{0, 1} inline functions to access actual
> mbuf fields.
> * introduce new inline functions for accessing rearm_data and
> rx_descriptor_fields1 descriptors.
> * adapt drivers to use new inline functions.
Accessor functions like these are BS for structures that are part of the public
API.
Nobody will use the accessor functions! When developing an application (or lib
or driver), the developer will look at the structure and access the relevant
fields directly; why would the developer start looking elsewhere for accessor
functions?
Another alternative would be to remove the rearm_data and rx_descriptor_fields1
fields from the structure, and in the drivers address the first field of the
group, and preferably add some static_asserts to check the sequence of the
fields they cover. I don't like this alternative, but I'm putting it out there
for discussion/inspiration.
I prefer the union+struct approach to visibly group the fields together.
Overall, I dislike approach taken in this version of the patch series.
On the surface, it has minimal changes to the mbuf structure.
But underneath, some of the fields (the markers) may or may not exist,
depending on compiler, and this fact is not obvious when looking at the
structure. I think this will degrade future MSVC compatibility for both
applications, libraries and PMDs.
As Thomas stressed, we should take special care of the mbuf structure!
It has to be modified for MSVC compatibility, so we have to find the best
compromise.
Personally, I prefer the previous approach over this version.
Maybe we need to compromise on API compatibility to make this a beautiful
modification.
@Thomas, looking at the mbuf and eal patches, what do you think about this
version of the series?
