Re: [dpdk-dev] [PATCH v2 4/6] net/pcap: add libpcap wrappers

On 3/3/2021 4:32 PM, Dmitry Kozlyuk wrote:

2021-03-02 11:22, Nick Connolly:

quoted

quoted

Is posix_memalign() used more extensively in SPDK? In DPDK, it's 2 PMDs:

Yes, there are about 80 references. A lot are in ISA-L where they are
#defined to _aligned_malloc and can be ignored, but there still several
in the rest of the code.

I think portable code should try sticking to C11 aligned_malloc().
BTW, _aligned_malloc (with "_") only supports power-of-2 alignment.

There's a related passage in MSVC blog:

	Due to the nature of the Windows heap, aligned_alloc support is
	missing. The alternative is to use _aligned_malloc.

https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/

quoted

quoted

quoted

    * Sockets are unfortunately specified as using close(). This is
      probably easy to address by rte_ wrapping all socket calls.

Which public DPDK APIs operate on sockets?
I don't like the idea of wrapping APIs like sockets or files.

I'm not sure about use in public APIs - I'd hope none do. I was thinking
about 'internal' use.

This is important (even more so for SPDK, I suspect), however, I'd like to
focus on public API first.

quoted

quoted

I drafted what I was talking about: adding address types and removing shims:

* librte_net/rte_ip.h then includes <netinet/ip.h> or <ws2tcpip.h>
    conditionally for AF_xxx, IPPROTO_xxx, and a few other constants.
    That's probably OK, there are similar places for Linux/FreeBSD differences,
    e.g. in <rte_endian.h>.

* Some IPPROTO_xxx constants are missing on Windows, so rte_ip.h has to
    provide them. I hope Mirosoft will add them to system headers one day.

* It affects cmdline (mostly), ethdev, security, crypto/dpaax.

Sounds good - well done!

...or not :)

If we can't help including <ws2tcpip.h>/<netinet/ip.h> from public headers,
might as well use `struct in_addr`, just replace `#include <netinet/ip.h>`
with `#include <rte_ip.h>` everywhere.

The only remaining issue will be `s_addr` macro on Windows that conflicts with
`struct rte_ether_addr` field `s_addr`. I don't know a better solution than
renaming `s_addr` to `src_addr` in DPDK (OTOH, it will be consistent with
`struct rte_ipvX_hdr` field naming).

Ferruh, what do you think?

No problem on the chosen name, that will work fine, but the 'struct 
rte_eth_addr' is public struct, we can't rename it without breaking the user 
applications.

Still it is possible to rename public struct, but it is a long process, need to 
send a deprecation notice and wait for next LTS, 21.11.

Ethernet header already has following, doesn't it help:
#undef s_addr /* Defined in winsock2.h included in windows.h. */