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 44F91A055D; Wed, 3 Mar 2021 17:32:45 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C403F160703; Wed, 3 Mar 2021 17:32:44 +0100 (CET) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by mails.dpdk.org (Postfix) with ESMTP id 2492F40683 for <dev@dpdk.org>; Wed, 3 Mar 2021 17:32:43 +0100 (CET) Received: by mail-lj1-f181.google.com with SMTP id r23so29485345ljh.1 for <dev@dpdk.org>; Wed, 03 Mar 2021 08:32:43 -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=BR9L6lbPckE/7kG3FQeLj8E3XrVSqQJEbUinYuAfv1M=; b=JfKsYptCOeDhoOSBHuefC70WqkLPU4+Iojx1fKBiuaXEhKpHnvEekqr6kGMjc3e9Ul mbNlXHqbJtte9Ve+Aba/hw2n70xm3xIm/fS2wdQ5ZtUwEuCHZ1JiB28oyW8elE1l1+ey mwwZkzxvB/SjP9WlKVXMlXcm+jYClPvaDTU2OkORAQFO18/ZOshcuXBdES6dNzCvRcwk AVYOMaKvUDwNMYj2736YHfpQvEbVjFYpyN3AlT+IkMKYw+aschHWHNbTueiNtan20ECy 0nu0qT8MO/CmRGCqNKdLhIpmYA9dMTuPsK/qmS49NOBkB2WFC1fcYFazPhuvCICLVcRw yVWQ== 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=BR9L6lbPckE/7kG3FQeLj8E3XrVSqQJEbUinYuAfv1M=; b=sCNEA2CNUXW7MkguD8poeOyz5sV2bqmLDKmyiX9H9lwM1rI/YsEfUiku5vd2W3BPaT UXbv6jcAIZRtIyzD/cw9Qhf5KkjmHo3mD117ydvHvHngt+I2a3iPELLxO3yh/u9TdPOi M9bUXwFRTgHl+DvfUe4uOgBTYuG0fqcq1KyRUyBQW20nYDKhcHPCPJWOfFmnINi9bCzN Xz/511WVyTtBiy31Qp9C3zcsDzYBSxdxpj8tUX/p9Up7xenja5kPYUeyaoPynVJlCBlC 1S9WLP9ophfiKBBKDf0mdv68MxDMZ0d9izeLu75uB+SonjLTb4C7MqkQaUOfbRwmXX7Q RH6A== X-Gm-Message-State: AOAM532xpOO0MmWreDDn6uKT7yBi4ru5iJaJl+sJvHiL2/FpNutH9izs EMrtAHYIUxwvK9goW7Fkquo= X-Google-Smtp-Source: ABdhPJywjfiMVgQFz1OLLvGwg5HQ8TdFbcDVMnY68vzVaggeSn0BSrQJbiwKgKdox1MqEqB7HNH5bg== X-Received: by 2002:a2e:b17b:: with SMTP id a27mr9425101ljm.62.1614789162565; Wed, 03 Mar 2021 08:32:42 -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 y23sm1218614ljm.53.2021.03.03.08.32.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Mar 2021 08:32:41 -0800 (PST) Date: Wed, 3 Mar 2021 19:32:40 +0300 From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com> To: Nick Connolly <nick.connolly@mayadata.io>, Ferruh Yigit <ferruh.yigit@intel.com> Cc: 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: <20210303193240.2b83d9c9@sovereign> In-Reply-To: <65bd9188-0fcd-ab0c-2434-6a298be19b1a@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> <20210226021001.73829588@sovereign> <826eb0d3-3c0b-7581-99be-77e9bb6e8fa2@mayadata.io> <20210302020559.6d3317d7@sovereign> <65bd9188-0fcd-ab0c-2434-6a298be19b1a@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 <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-03-02 11:22, Nick Connolly: > > Is posix_memalign() used more extensively in SPDK? In DPDK, it's 2 PMDs: > Yes, there are about 80 references. A lot are in ISA-L where they are > #defined to _aligned_malloc and can be ignored, but there still several > in the rest of the code. I think portable code should try sticking to C11 aligned_malloc(). BTW, _aligned_malloc (with "_") only supports power-of-2 alignment. There's a related passage in MSVC blog: Due to the nature of the Windows heap, aligned_alloc support is missing. The alternative is to use _aligned_malloc. https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ > >> * 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. > I'm not sure about use in public APIs - I'd hope none do. I was thinking > about 'internal' use. This is important (even more so for SPDK, I suspect), however, I'd like to focus on public API first. > > I drafted what I was talking about: adding address types and removing shims: > > > > * librte_net/rte_ip.h then includes <netinet/ip.h> or <ws2tcpip.h> > > 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 <rte_endian.h>. > > > > * 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. > Sounds good - well done! ...or not :) If we can't help including <ws2tcpip.h>/<netinet/ip.h> from public headers, might as well use `struct in_addr`, just replace `#include <netinet/ip.h>` with `#include <rte_ip.h>` everywhere. The only remaining issue will be `s_addr` macro on Windows that conflicts with `struct rte_ether_addr` field `s_addr`. I don't know a better solution than renaming `s_addr` to `src_addr` in DPDK (OTOH, it will be consistent with `struct rte_ipvX_hdr` field naming). Ferruh, what do you think?