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 1E111A0579; Thu, 8 Apr 2021 13:45:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AA61240698; Thu, 8 Apr 2021 13:45:44 +0200 (CEST) Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by mails.dpdk.org (Postfix) with ESMTP id 52E0E40138 for ; Thu, 8 Apr 2021 13:45:43 +0200 (CEST) Received: by mail-wm1-f42.google.com with SMTP id w203-20020a1c49d40000b029010c706d0642so3896850wma.0 for ; Thu, 08 Apr 2021 04:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=XB8tTG0/Sv+dBOarXMgh1rwiHaBSPVK5tPmsHcQa9HE=; b=CseJCDfd4AQUrlgArVSHMDuKIBS5vkQrvUe4N0gGTbUyZDweUDKBswAsiNYwSIA0Tp dx4uERGabwRl8dpEYdTfkc6R8mM/TcxT6A35zin67M0ca9f9YIZuPt+sk1PblROGPlZw Enfve9jBVPsRsod4x/A+3PmkoOQfjIeZw4u3OP+f3WCyLYPWCy7NcmtPo+wvD4J/CYVG SkPW7IkJCKiBo132ove9oDX6lewxOHbFpw9RJOrhZ5xXZyuuVK7aKXfO5iXW5dpKaMEW DkrJLDMu82fhv3DE8OjFL0gTapLWqxPIMjc3auJyJI/MFiy6cVulfX00+aOEdphYFIkT x4/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=XB8tTG0/Sv+dBOarXMgh1rwiHaBSPVK5tPmsHcQa9HE=; b=Cy9rtw8mnzIgxe307C8wrMfaE1NtLwu4+hiGmrehPB17hMhbM9aAGMjh5j9Yqu+or5 3jxFRvZDViKpTOMVe9IIWgV95A67EEEoupaRXrxjE7m03e4XlxSyvwWmRCJA0H46OwYg ukjUO2vB4zTfmC5BGwwa/jkXq/Iv1HnfiqMU2tifPD6maK3SjNP2h8V5tFwVgA0/Dt4N r2JAILdYUOGPSepRLcNJfi4MWnP0rdfQ9nsFMcZus2+pOPn7rga0M+syiGZHTz+/Z+Zm 4LkGkbK+Z77ri1qk2EbdN6J8DbjTKRU3OrxwEWtGZYFiPpFCHVk94jFRVL64dC7u7Tzl pRiQ== X-Gm-Message-State: AOAM532xaaRVH7Hbsgz85lsarsH9ZMCUNrXqaNrlqrqQ9jsuSlaCn2c+ dPnPTlaiinASjXvlGGpOXOTE5w== X-Google-Smtp-Source: ABdhPJxYDGNREztqNA22bikn7CilpclQUiHakKMsD0N+Usst3ce3clIhByrt/wepiNX07RVPgv73/g== X-Received: by 2002:a1c:3:: with SMTP id 3mr7421971wma.32.1617882343036; Thu, 08 Apr 2021 04:45:43 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id g1sm24921929wru.61.2021.04.08.04.45.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Apr 2021 04:45:42 -0700 (PDT) Date: Thu, 8 Apr 2021 13:45:41 +0200 From: Olivier Matz To: Dmitry Kozlyuk Cc: dev@dpdk.org, Tyler Retzlaff , Jie Zhou , Nick Connolly , Beilei Xing , Jeff Guo , Matan Azrad , Shahaf Shuler , Viacheslav Ovsiienko , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko Message-ID: <20210408114541.GV1650@platinum> References: <20210403234129.20296-1-dmitry.kozliuk@gmail.com> <20210407222249.6729-1-dmitry.kozliuk@gmail.com> <20210407222249.6729-5-dmitry.kozliuk@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210407222249.6729-5-dmitry.kozliuk@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH v8 4/4] net: provide IP-related API on any OS 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" Hi Dmitry, On Thu, Apr 08, 2021 at 01:22:49AM +0300, Dmitry Kozlyuk wrote: > Users of relied on it to provide IP-related defines, > like IPPROTO_* constants, but still had to include POSIX headers > for inet_pton() and other standard IP-related facilities. > > Extend so that it is a single header to gain access > to IP-related facilities on any OS. Use it to replace POSIX includes > in components enabled on Windows. Move missing constants from Windows > networking shim to OS shim header and include it where needed. > > Remove Windows networking shim that is no longer needed. > > Signed-off-by: Dmitry Kozlyuk > --- > drivers/net/i40e/i40e_fdir.c | 1 + > drivers/net/mlx5/mlx5.h | 1 - > drivers/net/mlx5/mlx5_flow.c | 4 +-- > drivers/net/mlx5/mlx5_flow.h | 3 +- > drivers/net/mlx5/mlx5_mac.c | 1 - > examples/cmdline/commands.c | 5 --- > examples/cmdline/parse_obj_list.c | 2 -- > lib/librte_cmdline/cmdline.c | 1 - > lib/librte_cmdline/cmdline_parse.c | 2 -- > lib/librte_cmdline/cmdline_parse_etheraddr.c | 6 ---- > lib/librte_cmdline/cmdline_parse_ipaddr.c | 6 ---- > lib/librte_cmdline/cmdline_parse_ipaddr.h | 2 +- > lib/librte_eal/windows/include/arpa/inet.h | 30 ---------------- > lib/librte_eal/windows/include/netinet/in.h | 38 -------------------- > lib/librte_eal/windows/include/netinet/ip.h | 10 ------ > lib/librte_eal/windows/include/rte_os_shim.h | 8 +++++ > lib/librte_eal/windows/include/sys/socket.h | 24 ------------- > lib/librte_ethdev/rte_ethdev.c | 12 +++---- > lib/librte_ethdev/rte_ethdev_core.h | 1 - > lib/librte_net/rte_ip.h | 7 ++++ > lib/librte_net/rte_net.c | 1 + > 21 files changed, 24 insertions(+), 141 deletions(-) > delete mode 100644 lib/librte_eal/windows/include/arpa/inet.h > delete mode 100644 lib/librte_eal/windows/include/netinet/in.h > delete mode 100644 lib/librte_eal/windows/include/netinet/ip.h > delete mode 100644 lib/librte_eal/windows/include/sys/socket.h I see it has already been discussed for posix functions like close() or strdup(), so I won't reopen the door too long ;) Since DPDK is a network-oriented project, it provides network defines or structure, prefixed with rte_. This API is on some aspects more complete than the one provided in libc (for instance, more protocol headers are available) . So, to me, it would make sense to define RTE_IPPROTO_* and replace usages of IPPROTO_*, and avoid inclusions of network libc headers in DPDK code. This can be done later, if there is a consensus. > diff --git a/drivers/net/i40e/i40e_fdir.c b/drivers/net/i40e/i40e_fdir.c > index c572d003cb..e7361bf520 100644 > --- a/drivers/net/i40e/i40e_fdir.c > +++ b/drivers/net/i40e/i40e_fdir.c > @@ -22,6 +22,7 @@ > #include > #include > #include > +#include > If I understand the logic, rte_ip.h provides OS-specific IP-related stuff (like IPPROTO_*), and rte_os_shim.h provides the POSIX definitions that are missing after including rte_ip.h. Would it make sense to include rte_os_shim.h from rte_ip.h, so that including rte_ip.h is always sufficient? Or is it because we want to avoid implicit inclusion of rte_os_shim.h? Thanks, Olivier