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 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 <dev@dpdk.org>; Fri, 26 Feb 2021 00:10:04 +0100 (CET)
Received: by mail-lf1-f48.google.com with SMTP id u4so11121325lfs.0
for <dev@dpdk.org>; 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 <dmitry.kozliuk@gmail.com>
To: Nick Connolly <nick.connolly@mayadata.io>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>, 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>
Message-ID: <20210226021001.73829588@sovereign>
In-Reply-To: <ac14b4fc-7e0a-f3f5-a75d-65bc6e8f90fa@mayadata.io>
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>
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 <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>
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, <ws2tcpip.h=
>) with
> > some additions (but no hacks), they create no issues to any existing co=
de.
> >
> > The only workaround remaining is `#undef s_addr` in <rte_ether.h>.
> >
> > 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 <ws2tcpip.h>
> >
> > /* 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?