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 7005FA054F; Tue, 2 Mar 2021 00:06:04 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E2D2540693; Tue, 2 Mar 2021 00:06:03 +0100 (CET) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by mails.dpdk.org (Postfix) with ESMTP id 8C09C40142 for ; Tue, 2 Mar 2021 00:06:02 +0100 (CET) Received: by mail-lf1-f43.google.com with SMTP id d3so28213837lfg.10 for ; Mon, 01 Mar 2021 15:06:02 -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=8AB1bXkeaDTF0HrqlCqANteFwZzvOO1cKcmKbOrqclM=; b=WG/uIpAEfPBwsKv0QzoI9cbvdmHfTkU8pT5AxtM3svrI4urrHOltpHV/6vzKVh/6vg mYGJudQimBju4BAkYtfdT22GOPQRkMGqgB7hQ7bUlpjFcrN27OW3AyCzzHgPCH17eDza jvbvXl63SIrp1S3BOni0YJcGmyMYD1OQzfp3BVXF8D203NGlDGaJNYZ/8d3+dkataTvw amsV2Xs3kroY25O5VBmo0IQ1dzxR3LUgy3V6CauB16ycURvQqzb4a74kV37W0WGbC6cS MrNO/mYNfdNhuWp/Ri/5CzK7LCd8De9cFLR4COU52gCbUZC9enDt4CvbqI1+KFFjSb2z lUkQ== 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=8AB1bXkeaDTF0HrqlCqANteFwZzvOO1cKcmKbOrqclM=; b=F02SOGFp5AkdmYpLhyTFX/PYbi0SoEIl8ZWXgLAlWBlzjhruZAAywInup2tJlPDJCA S5JaXkLwkBlTct4ua9z3Bn4fciC7xnbXBervBC4wApBe6gZnvbh7dGSwLUShvMjukyIW cDqHSy4Cs2LPm3L2fKE/+oy85UmpM9BR6yOqw8aBFJU3R5AY3O8du/Z52YDqcLFdk3UR /lbauKoBZMruxCqEZwIMLYtkT6+0pkOzpdFFRhAMBQh2d0dpDQis4MhUc+dQ1SmOJHBj FfoJkhoO6sWuxG2HrxSv8s/2u9z6bw/rgZZ8RpAbStXI13mw3BYtrPpYkkUJb6iHwL65 EK7Q== X-Gm-Message-State: AOAM530/PCtu9DZnS8zXpbLwed4M98lURw7akwWQgv2l21T6h0q/emIo HXd/LjnsS4qVeFm8BmsiXrY= X-Google-Smtp-Source: ABdhPJxipo5ZrDMDr2jV1/llc7eukpd0dvnmyqKdY1pTFeWaCO2q6koLJCUnvzbIZ5r5Cjqee+wQwA== X-Received: by 2002:a05:6512:2304:: with SMTP id o4mr10993302lfu.197.1614639962080; Mon, 01 Mar 2021 15:06:02 -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 f23sm2611652ljn.131.2021.03.01.15.06.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Mar 2021 15:06:01 -0800 (PST) Date: Tue, 2 Mar 2021 02:05:59 +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: <20210302020559.6d3317d7@sovereign> In-Reply-To: <826eb0d3-3c0b-7581-99be-77e9bb6e8fa2@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> <20210226021001.73829588@sovereign> <826eb0d3-3c0b-7581-99be-77e9bb6e8fa2@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=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-03-01 21:43, Nick Connolly: > > Complete removal of non-standard dependencies in headers is within a grasp. > > Then we can remove shims and include whatever needed. > > Thoughts? > Sounds good. A couple of 'gotchas' that I've come across (but may not be > an issue for DPDK): > > * Memory allocation / free that spans a dll boundary (see earlier email). Not sure which email you mean, could you give a link? > * posix_memalign is unfortunately specified as using free(), so we'll > either have to modify the calls to rte_posix_memalign / > rte_free_memalign (which means code analysis to find which free > calls need changing), or wrapper free() to distinguish the two types > of memory somehow. I 'solved' this for SPDK by using posix_memalign > for everything and I have a vague recollection that the mingw libc > does something similar. Is posix_memalign() used more extensively in SPDK? In DPDK, it's 2 PMDs: * mlx5 PMD uses _aligned_malloc/_aligned_free on Windows; * dpaax (PMD family) uses posix_memalign() to allocate pages. There are "malloc" and "alloc_size" attributes that can help code analysis. > * 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. (Yes, we're discussing libpcap API wrappers in this thread, but we already agreed they are a mistake and they were internal in the first place.) 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.