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 2A5C2A034F; Fri, 26 Feb 2021 00:10:07 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9C15E40A4B; Fri, 26 Feb 2021 00:10:06 +0100 (CET) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by mails.dpdk.org (Postfix) with ESMTP id AA410407FF for ; Fri, 26 Feb 2021 00:10:04 +0100 (CET) Received: by mail-lf1-f48.google.com with SMTP id u4so11121325lfs.0 for ; Thu, 25 Feb 2021 15:10:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=uPsc7YOdmQkDqyfHaAanh8x445F9bwoHBXtbdId7rr4=; b=FP/tTadUTbCfL1A4Mhk+QY6xI9eFJHRUBQJxwtI/M5paQxWM1WWAqlSd7Hti8n2mO8 UG1/g7LXwluu9PL0oJrRpqmYnMcO35WenipwMvn/UdsrJP7CjFU7iinD886ZmoHQFGof /Wm5VKp6agcTRqu5l+uPUeZoHT1YK0DaN/fuZmqux2Li1b3Fsk4+8YSiskY2yWI0VpxP gtMVdGrcCR6DHnPBHFxwV8fF9Qnmg4sKws1/SGO+bcvyVK5yF0J9ivS+iAaAz9FJWu43 FN3NjeDc8zto6FU6Ej7LZ0+HY671xeMtMNAGAm/qhmD/B/YQUvwWQIMotwWmPKi6L1EU Sp4A== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=uPsc7YOdmQkDqyfHaAanh8x445F9bwoHBXtbdId7rr4=; b=L5UO2g21gBRQl+9XAoy8hFHxUkzbAxsjRXb6CFPH2wY7j7B8TeIFBMRHiWurUAkF9t nRw7+tLUPZ/qChWkAOGx7TL3BYv0dNofa0wtJfsN2gA2i7rDVh8KkQUVA1e2S5CsquJ/ V5K1vLKfoi9DHcsDsHmG+CEMIvZhYnFKhFbrghTRh47e1VIwfzrmtjsY20YQYDMoqHKf TR4ZF8MFiy6h5pm6w+ga12Y39xftSzdjbJ6JHDR59nd4vSXFKtn4HoLFp71Lf6UGGfuX YHoWYsXTeDCu+Ss87vc/BeeMo7I/sgGP88JDgGldXL7EEDeYIpFnf7iqD8LZlJ0N7G9W b+Qg== X-Gm-Message-State: AOAM532sWMlf7dxK0dFftEUHDv3F1aJXjm6A8ggiHa4GXo/fK6I4d/vn 2QlsrXcm5c1y6FIj10uHUPg= X-Google-Smtp-Source: ABdhPJxXjg0jzOcHN3yuZf71q2DZB6ntcNrsXNdZA+W3h8mZ+MkpE2awQ5fUaY70p25vCLNgRS+M1A== X-Received: by 2002:ac2:5188:: with SMTP id u8mr76221lfi.564.1614294604200; Thu, 25 Feb 2021 15:10:04 -0800 (PST) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id w9sm1214221lfn.308.2021.02.25.15.10.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Feb 2021 15:10:02 -0800 (PST) Date: Fri, 26 Feb 2021 02:10:01 +0300 From: Dmitry Kozlyuk To: Nick Connolly Cc: Ferruh Yigit , dev@dpdk.org, Tyler Retzlaff , Mike Wells , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam , Jie Zhou Message-ID: <20210226021001.73829588@sovereign> In-Reply-To: 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> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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" 2021-02-25 20:31, Nick Connolly: > > Your comment made me revise Windows EAL networking shims. Surprisingly,= if > > changed to expose Windows networking headers (specifically, ) with > > some additions (but no hacks), they create no issues to any existing co= de. > > > > The only workaround remaining is `#undef s_addr` in . > > > > So maybe this commit can be dropped, if Windows EAL networking headers = be > > reworked in the following way: > > > > #if defined min > > #define USER_EXPLICITLY_WANTS_WINDOWS_H > > #endif > > > > #include > > > > /* hide definitions that break portable code, > > * e.g. it had to be done once already for i40e > > */ > > #ifndef USER_EXPLICITLY_WANTS_WINDOWS_H > > #undef min, max, ... > > #endif > > > > #define what's missing from Windows headers, e.g. IPPROTO_SCTP > > > > + Windows maintainers, Nick Connolly, and Jie Zhou to discuss. =20 > In my opinion, there are long term maintenance issues either way round. >=20 > Wrapping the system headers hides the details and keeps the code 'clean', > but has to work with multiple compiler environments and versions of the > headers - not always straightforward.=C2=A0 You're probably right. We had an exchange with Tyler, let me quote: [DmitryK] > I'm pretty sure no DPDK header really needs anything beyond standard C, > but one exception: intrinsic functions for vector instructions. > Struct in_addr? An oversight, there's rte_ether_addr, should be rte_ip_ad= dr. Here's a complete list of offending files included from public headers, with comments on usage: POSIX netinet/in.h netinet/ip6.h netinet/ip.h cmdline: struct in_addr, struct in6_addr, 6 constants net: ditto security: ditto pthread.h eal: not used ethdev: pthread_mutex_t flow_ops_mutex; sched.h eal: cpu_set_t telemetry: rte_cpuset_t (not used?) sys/types.h ehtdev: not needed (FILE?) net: not needed mbuf: ditto pci: ditto security: ditto sched: ditto Unix sys/queue.h (acl, eal, hash, lpm, mempool, pci, ring, table, bus/{fslmc,pci,vdev,vmbus}, net/{memif,tap}) multiprocessing Thread-related stuff will go away as rte_thread.h expands. Network headers are not much needed, as you can see above. Other headers mostly not needed or can be replaced with standard ones. Replacing `in_addr` with and `rte_ip_addr` will break API, but not ABI, because it's essentially the same thing. We can define new types conditionally, as it was done for struct cmdline, if need be. Complete removal of non-standard dependencies in headers is within a grasp. Then we can remove shims and include whatever needed. Thoughts?