diff mbox series

doc: announce renaming of rte_ether_hdr fields

Message ID 20210303225121.16146-1-dmitry.kozliuk@gmail.com (mailing list archive)
State New
Delegated to: Thomas Monjalon
Headers show
Series doc: announce renaming of rte_ether_hdr fields | expand

Checks

Context Check Description
ci/github-robot success github build: passed
ci/travis-robot success travis build: passed
ci/intel-Testing success Testing PASS
ci/Intel-compilation success Compilation OK
ci/checkpatch success coding style OK

Commit Message

Dmitry Kozlyuk March 3, 2021, 10:51 p.m. UTC
It is proposed to rename fields of `struct rte_ether_hdr`,
`s_addr` tp `src_addr` and `d_addr` to `dst_addr`,
due to the clash with system macro on Windows.
Until remaining is done in 21.11, a workaround can be used.

Windows Sockets headers contain `#define s_addr S_un.S_addr`, which
conflicts with `s_addr` field of `struct rte_ether_hdr`. Undefining
this macro in <rte_ether.h> is breaking some usages of DPDK
and Windows headers in one file.

Example 1:

    #include <winsock2.h>
    #include <rte_ether.h>
    struct in_addr addr;
    /* addr.s_addr = 0;     ERROR: s_addr undefined by DPDK */

Example 2:

    #include <rte_ether.h>
    #include <winsock2.h>
    struct rte_ether_hdr eh;
    /* eh.s_addr.addr_bytes[0] = 0;     ERROR: `addr_s` is a macro */

It is not mandatory to rename `d_addr`, this is for consistency only.
Naming in `rte_ether_hdr` will also resemble `rte_ipv4/6_hdr`.

Workaround is to define `struct rte_ether_hdr` in such a away that
it can be used with or without `s_addr` macro (as defined on Windows)
This can be done for Windows only or for all platforms to save space.

    #pragma push_macro("s_addr")
    #ifdef s_addr
    #undef s_addr
    #endif

    struct rte_ether_hdr {
        struct rte_ether_addr d_addr; /**< Destination address. */
        RTE_STD_C11
        union {
            struct rte_ether_addr s_addr; /**< Source address. */
            struct {
                struct rte_ether_addr S_un;
                /**< MUST NOT be used directly, only via s_addr */
            } S_addr;
            /*< MUST NOT be used directly, only via s_addr */
        };
        uint16_t ether_type; /**< Frame type. */
    } __rte_aligned(2);

    #pragma pop_macro("s_addr")

Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
---
 doc/guides/rel_notes/deprecation.rst | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Stephen Hemminger March 3, 2021, 11:54 p.m. UTC | #1
> +
> +* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
> +  will be renamed to ``src_addr`` and ``dst_addr`` respectively in DPDK 20.11
> +  in order to avoid conflict with Windows Sockets headers.

If those fields were a problem now, there might be others in future.
Don't use src_addr and dst_addr because those are already used in rte_ipv4_hdr.

Linux and FreeBSD use:

struct ether_header
{
  uint8_t  ether_dhost[ETH_ALEN];	/* destination eth addr	*/
  uint8_t  ether_shost[ETH_ALEN];	/* source ether addr	*/
  uint16_t ether_type;		        /* packet type ID field	*/
} __attribute__ ((__packed__));

So why not ether_dhost/ether_shost?
Dmitry Kozlyuk March 4, 2021, 7:09 a.m. UTC | #2
2021-03-03 15:54, Stephen Hemminger:
> > +
> > +* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
> > +  will be renamed to ``src_addr`` and ``dst_addr`` respectively in DPDK 20.11
> > +  in order to avoid conflict with Windows Sockets headers.  
> 
> If those fields were a problem now, there might be others in future.

One I can think of is `min` and `max` macros from `windows.h`: they are used
as field names in `rte_compressdev.h` and `rte_cryptodev.h` (and more than
once have they been worked around in PMD code, see i40e and ice patches).
Do you prefer a single notice for all such conflicts we can identify now?

> Don't use src_addr and dst_addr because those are already used in rte_ipv4_hdr.

Not sure what DPDK policy is: `rte_ipv4/6_hdr` use completely custom names,
while `rte_arp_hdr` uses traditional names with `arp_` prefix.
Coming from C++, I chose the former approach, but it's not a strong opinion.

> Linux and FreeBSD use:
> 
> struct ether_header
> {
>   uint8_t  ether_dhost[ETH_ALEN];	/* destination eth addr	*/
>   uint8_t  ether_shost[ETH_ALEN];	/* source ether addr	*/
>   uint16_t ether_type;		        /* packet type ID field	*/
> } __attribute__ ((__packed__));
> 
> So why not ether_dhost/ether_shost?

Works for me, let's see what others think.
diff mbox series

Patch

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 82c1a90a3..f7be10543 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -125,3 +125,7 @@  Deprecation Notices
 * cmdline: ``cmdline`` structure will be made opaque to hide platform-specific
   content. On Linux and FreeBSD, supported prior to DPDK 20.11,
   original structure will be kept until DPDK 21.11.
+
+* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
+  will be renamed to ``src_addr`` and ``dst_addr`` respectively in DPDK 20.11
+  in order to avoid conflict with Windows Sockets headers.