From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 80D6EA055D;
	Wed,  3 Mar 2021 17:47:33 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 07325160714;
	Wed,  3 Mar 2021 17:47:33 +0100 (CET)
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
 by mails.dpdk.org (Postfix) with ESMTP id B007740683
 for <dev@dpdk.org>; Wed,  3 Mar 2021 17:47:31 +0100 (CET)
IronPort-SDR: qztg1Fm42fHIIHccJTjrk/GeDR+H48A57cQbRREb3XlCV9zGDbRVWJelukG6HSgj90p84q0gQm
 cBbWqzFmL7Qg==
X-IronPort-AV: E=McAfee;i="6000,8403,9912"; a="251282879"
X-IronPort-AV: E=Sophos;i="5.81,220,1610438400"; d="scan'208";a="251282879"
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
 by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 03 Mar 2021 08:47:30 -0800
IronPort-SDR: GOOXEssZv1fialn9r+FtTUZq9IkH10QOKo5tMa1QSjJIqxTQ9ASK74y+GLY2ey0veqnpj0L52D
 tsNTsL/8vMIA==
X-IronPort-AV: E=Sophos;i="5.81,220,1610438400"; d="scan'208";a="506851336"
Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.9.23])
 ([10.252.9.23])
 by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 03 Mar 2021 08:47:28 -0800
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>,
 Nick Connolly <nick.connolly@mayadata.io>
Cc: dev@dpdk.org, Tyler Retzlaff <roretzla@microsoft.com>,
 Mike Wells <mike.wells@telchemy.com>,
 Narcisa Ana Maria Vasile <navasile@linux.microsoft.com>,
 Dmitry Malloy <dmitrym@microsoft.com>,
 Pallavi Kadam <pallavi.kadam@intel.com>, Jie Zhou <jizh@linux.microsoft.com>
References: <20210214012013.23165-1-dmitry.kozliuk@gmail.com>
 <20210214021616.26970-1-dmitry.kozliuk@gmail.com>
 <20210214021616.26970-5-dmitry.kozliuk@gmail.com>
 <6c5e9d34-abfa-d808-eef0-165315baf3ce@intel.com>
 <20210225220440.2bda87c3@sovereign>
 <ac14b4fc-7e0a-f3f5-a75d-65bc6e8f90fa@mayadata.io>
 <20210226021001.73829588@sovereign>
 <826eb0d3-3c0b-7581-99be-77e9bb6e8fa2@mayadata.io>
 <20210302020559.6d3317d7@sovereign>
 <65bd9188-0fcd-ab0c-2434-6a298be19b1a@mayadata.io>
 <20210303193240.2b83d9c9@sovereign>
From: Ferruh Yigit <ferruh.yigit@intel.com>
X-User: ferruhy
Message-ID: <e742d4a5-41c7-d78b-e6e2-d2be853c6e92@intel.com>
Date: Wed, 3 Mar 2021 16:47:24 +0000
MIME-Version: 1.0
In-Reply-To: <20210303193240.2b83d9c9@sovereign>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [dpdk-dev] [PATCH v2 4/6] net/pcap: add libpcap wrappers
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 3/3/2021 4:32 PM, Dmitry Kozlyuk wrote:
> 2021-03-02 11:22, Nick Connolly:
>>> 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/
> 
>>>>     * 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.
> 
>>> 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. */