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 34B2F43FD8; Wed, 8 May 2024 09:48:28 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0387240A6E; Wed, 8 May 2024 09:48:28 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 4BC28402AF for ; Wed, 8 May 2024 09:48:26 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id ED9C5939C for ; Wed, 8 May 2024 09:48:25 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id DE813939B; Wed, 8 May 2024 09:48:25 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.3 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 8E82E9362; Wed, 8 May 2024 09:48:23 +0200 (CEST) Message-ID: <56335dd0-0d9c-4725-b0c9-3d2cb438a436@lysator.liu.se> Date: Wed, 8 May 2024 09:48:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC v2] net/af_packet: make stats reset reliable To: =?UTF-8?Q?Morten_Br=C3=B8rup?= , Stephen Hemminger , Ferruh Yigit Cc: "John W. Linville" , Thomas Monjalon , dev@dpdk.org, =?UTF-8?Q?Mattias_R=C3=B6nnblom?= References: <20240425174617.2126159-1-ferruh.yigit@amd.com> <20240426143848.2280689-1-ferruh.yigit@amd.com> <108e0c40-33e7-4eed-83de-eaedee454480@lysator.liu.se> <238675d1-b0bb-41df-8338-a1052c1a88c1@lysator.liu.se> <20240507075128.36484b4b@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35E9F423@smartserver.smartshare.dk> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F423@smartserver.smartshare.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 On 2024-05-07 18:00, Morten Brørup wrote: >> From: Stephen Hemminger [mailto:stephen@networkplumber.org] >> Sent: Tuesday, 7 May 2024 16.51 > >> I would prefer that the SW statistics be handled generically by ethdev >> layers and used by all such drivers. > > I agree. > > Please note that maintaining counters in the ethdev layer might cause more cache misses than maintaining them in the hot parts of the individual drivers' data structures, so it's not all that simple. ;-) > > Until then, let's find a short term solution, viable to implement across all software NIC drivers without API/ABI breakage. > >> >> The most complete version of SW stats now is in the virtio driver. > > It looks like the virtio PMD maintains the counters; they are not retrieved from the host. > > Considering a DPDK application running as a virtual machine (guest) on a host server... > > If the host is unable to put a packet onto the guest's virtio RX queue - like when a HW NIC is out of RX descriptors - is it counted somewhere visible to the guest? > > Similarly, if the guest is unable to put a packet onto its virtio TX queue, is it counted somewhere visible to the host? > >> If reset needs to be reliable (debatable), then it needs to be done without >> atomics. > > Let's modify that slightly: Without performance degradation in the fast path. > I'm not sure that all atomic operations are slow. Relaxed atomic loads from and stores to naturally aligned addresses are for free on ARM and x86_64 up to at least 64 bits. "For free" is not entirely true, since both C11 relaxed stores and stores through volatile may prevent vectorization in GCC. I don't see why, but in practice that seems to be the case. That is very much a corner case. Also, as mentioned before, C11 atomic store effectively has volatile semantics, which in turn may prevent some compiler optimizations. On 32-bit x86, 64-bit atomic stores use xmm registers, but those are going to be used anyway, since you'll have a 64-bit add. > But you are right that it needs to be done without _Atomic counters; they seem to be slow. > _Atomic is not slower than atomics without _Atomic, when you actually need atomic operations.