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 DFE7EA034F; Thu, 25 Feb 2021 20:04:42 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AA6F51608B1; Thu, 25 Feb 2021 20:04:42 +0100 (CET) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by mails.dpdk.org (Postfix) with ESMTP id 2D23E1608A1 for ; Thu, 25 Feb 2021 20:04:42 +0100 (CET) Received: by mail-lf1-f42.google.com with SMTP id w36so10191454lfu.4 for ; Thu, 25 Feb 2021 11:04:42 -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=GafSbvGeVQN3ElLL3MLEszqNrxGieV0C4O8tyaZsbUY=; b=T3od/3vWlYxCudNdlId3JjBzc76anGjtBDvA+HMNFJ+GvuV0gj6gOlLDEkvJxKAAQp r1z5WO0ZkotIVrZ2+hZZivungCQLNInjC0zuCO0bYASobI/fUO+3X9zGSk5fNX72X+mU jy37wbr2jbaDXovP9LNsHr4GQGo9EViAs/T6cuJa/uRNIwPDERxYOHxTK4s0RDyg6p9M SFmfGJdxXm4jS03tQUSa/5xUD3W6K8uTH+YoORFtIPOxwRFuf8eJ07btdzkAalifGUoP khsyOYglS6twEklpH249YHlKaKxPFxo8o7cWci7LFK3mKr8GzI+hftj/hi2DKlpl9CIj yZnQ== 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=GafSbvGeVQN3ElLL3MLEszqNrxGieV0C4O8tyaZsbUY=; b=W1GX2pCc3ZwEDhUhVBzrBCXl4nmwV6ejtv6a7a8I0PW/J3JMyYAJX+nB8r1yCMZvVb kEvHfwIy1CsGSEMxBU2ithFr77q+yQq0UB+iGoVHtIgphMj+iCwT6LPduNf3GQRAwGIa bDEbXM+vJADs+1Ct+MpZ8RCfh1bXfoK1ma9TWxfK+0LBM0ht/d2VDCkkJ0yRpzuCnEae 4bNpdJOxj8/87k9vIc8CzRrWwJsQFSGwlRFc5WaetSPgrpQ/7sgVSSTGlPm7JaN7d8pu KBQ2zMFxtKUsgKpwQSadGCkLP046MYKSOm+CvChvALRkdTgG7M6SYW0Uj3uksVjjPM3i AMHQ== X-Gm-Message-State: AOAM532vUc7J5wjzQqOtXBogwKM4rB2TAL54quusvuplRNXqtu6qA2DX ZI/r7zheYBeLEsARzBjWyoA= X-Google-Smtp-Source: ABdhPJwiTIh7uXH6gQwhja2RZqDSIQcu2FaLZ6GfqFXPOLknABdk3tNFEFXL90YxwJ5CjcKgtPJxJA== X-Received: by 2002:a05:6512:3390:: with SMTP id h16mr2640311lfg.479.1614279881748; Thu, 25 Feb 2021 11:04:41 -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 a6sm1168852lfl.15.2021.02.25.11.04.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Feb 2021 11:04:41 -0800 (PST) Date: Thu, 25 Feb 2021 22:04:40 +0300 From: Dmitry Kozlyuk To: Ferruh Yigit Cc: dev@dpdk.org, Tyler Retzlaff , Mike Wells , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam , Nick Connolly , Jie Zhou Message-ID: <20210225220440.2bda87c3@sovereign> In-Reply-To: <6c5e9d34-abfa-d808-eef0-165315baf3ce@intel.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> 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=US-ASCII Content-Transfer-Encoding: 7bit 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 14:59, Ferruh Yigit: > On 2/14/2021 2:16 AM, Dmitry Kozlyuk wrote: > > libpcap headers can expose OS headers. On Windows, system networking > > headers are incompatible with DPDK ones, causing multiple name clashes. > > API of libpcap itself involves a non-standard u_char type. > > > > Add a limited set of trivial libpcap wrappers, so that libpcap headers > > are not included directly by OS-independent PMD code. Use EAL types and > > functions for time instead of POSIX ones. > > > > It is not nice to duplicate the pcap struct and macros and have dpdk versions of > them, it may have long term maintanance issues too. > > What are the clashes in question? > > If they are macros, can the issue solved after undefining some after including > 'pcap.h'? > > And at the end of the day, shouldn't we need to resolve these clashes globally > since we may hit same things with other PMDs or libraries as we enable them. I > am for a global solution instead of these changes in pcap, but I guess question > is how possible that global solution is.. 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 code. 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.