From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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 , Nick Connolly Cc: dev@dpdk.org, Tyler Retzlaff , Mike Wells , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam , Jie Zhou 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> <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 X-User: ferruhy Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 or >>> 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 . >>> >>> * 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 / from public headers, > might as well use `struct in_addr`, just replace `#include ` > with `#include ` 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. */