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 021D6A054F; Tue, 2 Mar 2021 12:22:47 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8534422A284; Tue, 2 Mar 2021 12:22:47 +0100 (CET) Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by mails.dpdk.org (Postfix) with ESMTP id A27FF4014E for ; Tue, 2 Mar 2021 12:22:46 +0100 (CET) Received: by mail-wr1-f48.google.com with SMTP id h98so19430044wrh.11 for ; Tue, 02 Mar 2021 03:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mayadata-io.20150623.gappssmtp.com; s=20150623; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=hR3n4iEnb+R6a/ZvtzpnzJeyWLgKt+sDIi5GfGhs/SM=; b=njUpfThgxH9LUog0BMRbt8De0Lirc8C6qJt8f3R4vdEH9PopR7pOxO4LlR/dococX/ xrA85nTsCLQ3+yI1nIq/w1s8T+3cCL0koZsbsoRacFRBCcjpHmn1JzvIR4KHoqwMB61R 6Clh+TuJBFplnfsObvEWSq+R11Er8BKBWj3h8sni7Pae4NZWgObEkWNTib4eccv3LMm0 ZaH9xlwaaq80t5qp7HRKS8t467I98TEA5f4MGUKnnFJu3EyYFC++ircSQbFFyYokijZa xgEEVH0dgtQBJ4BzVsmybUsXiTAksgmX0xPL403PGbMGBXgUCTe1+jxDYpwMxASx1j7Z yn3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=hR3n4iEnb+R6a/ZvtzpnzJeyWLgKt+sDIi5GfGhs/SM=; b=mQBvcklRG51SINkVXfjyj9524dpesZMhfMMsWYBg0GhEwkvpr2Pmv26zRZHwNZ0ALV Z1aozc+QbqP/BwutRaPIPvnSg+plcnS/Bs84RvvetqXebC9hZ2+QDncKekjXEdZTUy+Y HSZpLSrsrHCkBKMUXtkk91qzsclNq27k0+Q1Yez7A00PJOF1Vjlngstg9sTjvzQ0ZngN NRVYtESlHTUNwcEOFL2KMJOVoKtkQHkVXFryfDPwinI+KEubKlePeNsBs9PTLS2Zfjs8 QokxY873Vw6YbYtO2+xEB0QbVypNQWMFpZPA8ALwGZTL8C9+6vzHIaEtuHtJmlrP/g74 Jw9Q== X-Gm-Message-State: AOAM53340hCy6nti4Ev7tjB55gTHtCp9hmJ0+4Kb7JXNtO1h9qeo3qtH j/AJAF6O3t3nfLIWdtaAr329ew== X-Google-Smtp-Source: ABdhPJxYhI3iNXwCKLOYz6VpOUHobMfN4C7KqTRzD9cZokfUrdsjETSR4evs0CXSGPWeXovZ8MXGBw== X-Received: by 2002:adf:a1d8:: with SMTP id v24mr21067327wrv.378.1614684166271; Tue, 02 Mar 2021 03:22:46 -0800 (PST) Received: from [192.168.0.33] (cpc98320-croy25-2-0-cust77.19-2.cable.virginm.net. [80.235.134.78]) by smtp.gmail.com with ESMTPSA id h22sm2912611wmb.36.2021.03.02.03.22.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Mar 2021 03:22:45 -0800 (PST) From: Nick Connolly X-Google-Original-From: Nick Connolly To: Dmitry Kozlyuk Cc: Ferruh Yigit , dev@dpdk.org, Tyler Retzlaff , Mike Wells , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam , Jie Zhou 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> <20210302020559.6d3317d7@sovereign> Message-ID: <65bd9188-0fcd-ab0c-2434-6a298be19b1a@mayadata.io> Date: Tue, 2 Mar 2021 11:22:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210302020559.6d3317d7@sovereign> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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" > 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. >> * 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. The tricky issue here is that on Linux/FreeBSD socket() returns a small integer file descriptor whereas Windows returns a SOCKET type (which is a UINT_PTR and so larger than the 'int' that an fd occupies). In practice it looks as though SOCKET usually returns a small integer, but as far as I can see from the documentation it depends on the software stack that is in use. Even if it's a small integer, I don't think it has any correlation to the file descriptor table in the crt, which means that calls to read/write/close will all need to be handled so that they work. > (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. Sounds good - well done! Regards, Nick