From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792571178; b=oD7mFrxVsf0nhvK+tebFKDBKiPhJO3r3tUc7fMMvCud7H5qUQGiwfWhefZiFA7KAnSYF eggnoxSbj8CyvzlVl8nqfdXVqJVPyb0QqnSf2dyUbQYnR2NU0hMFuXwcBWRhjqUJRrzO7 qGCeuVxLd9rqvaKO8Z9kvH8usF34q5plu8Z9mSS+EH1cV2CoM7iG8d6WWWQB2WWwrRjgD Fk8sXcrx+TPOYfxveXwW78R0lrRejM/KQzMBbMC1cF32Tf35aFuZAfKGVPLQPwoeWvrCH DFJNv8A/QGtIjD6pJoiLJxwsTtRdqzBaRuqnuuwQzg8CNXiDDksEvjk5OXc9TyblcTA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792571178; h=DMARC-Filter:DKIM-Signature:Received:X-MC-Unique: X-Mimecast-MFC-AGG-ID:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received: X-Received:Received:Message-ID:Date:MIME-Version:User-Agent:Subject: To:Cc:References:Content-Language:From:In-Reply-To:Content-Type: Content-Transfer-Encoding; bh=F54D21K1objmsAiJjjGq1fpJPBej+JQYWf+LanDUQ6g=; b=2PU1XyEzqsw51pj+uKMde5mROw5DHHm9EJAA3+lC00xB+Ly0u2Vra3pxpFXLCF880TKK R3rlIfJPwI67A1cHsMaAUAm//9XgZPw2IwBRqIVTHCTwv7voV6PmbLiUx+wHq/mn1gwsh DSG123+uXR8VY7HpCBHc8hYhxoBbOlE2SoiF4M8DwU+nswgOEYJz+peJqRKan4FjrCz3k o2guQb5RDE02d2rVjk3LHG7fXgfNohjOwJyJXPAhEmDA9iFFIuzaQM3ZKMlWAXz4IrQbl M+joQgaNDcyMq90PaUBqyxKC1PDdvLridf7m7kJ6PJqfVPNx817oeZP/uc2fPMjzFLA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Je7dhhbv; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=google header.b=s4Hai8Ay; arc=none smtp.remote-ip=170.10.129.124 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 53D54606A31C for ; Wed, 21 Oct 2026 08:26:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 53D54606A31C Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Je7dhhbv; dkim=pass (2048-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=google header.b=s4Hai8Ay DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1792571177; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=F54D21K1objmsAiJjjGq1fpJPBej+JQYWf+LanDUQ6g=; b=Je7dhhbvzNER1jHVuKlpmIXv1qvSzdI21/eKKZDmTsRSOTv114jamxt782T0ZTq+4MX2jI e+bLvQapiaa2M5YHW9KOLoI6Kh5E/SRIJ+g7wdmYw11DoVklGqScR8tMW2keFtbcmxzfbS gAeGTyedHTQ/wzWhWtn14+0mN0jPaJE= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-663-3dob9xIVPRS6kNrXHRXL7A-1; Wed, 21 Oct 2026 08:26:15 +0000 X-MC-Unique: 3dob9xIVPRS6kNrXHRXL7A-1 X-Mimecast-MFC-AGG-ID: 3dob9xIVPRS6kNrXHRXL7A_1792571175 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-48dea677afcso363769f8f.1 for ; Wed, 21 Oct 2026 01:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1792571175; x=1793175975; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=F54D21K1objmsAiJjjGq1fpJPBej+JQYWf+LanDUQ6g=; b=s4Hai8AyrXwfJ4ythQ96hnncBtu7korBgLD5zKy8UQztPmsXsxD8eGCBI7ufxiclw2 1t+snpuNGCz9FpYzHlt7Scxbn28FoW6wJYzjcQ73t0XQPC4zgWMP2Mwq8zZWuiKBT8BY t6drvno7tlNBoqjtjeCewKp2spFI00/V4UQhTKmO6EJ1Yt/cZ05QKmFpyHzdtJUUc/0S wZSaVzerGgqP0aE6qDFHuGIPLqyCMk7dwxFoslorPuojq/rod7fRlR4XLbt5bETpoti9 g1ioA5cdYbeOrCeNeiCzfyyojsNYC83KeGzAUPDeMLu1pHu56azpnhDFn9egH0jSSqOp CJ1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792571175; x=1793175975; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=F54D21K1objmsAiJjjGq1fpJPBej+JQYWf+LanDUQ6g=; b=YfGQ1sFZPphUCNUBfAI6+fenNkurQysItqG+tvQ98erIsmtPCPrQoQrACgBiSZW0VD fE8/3E08F8G1h+W1bm640qpG2hqR9E/ozF77k/TgXelqrzNir4q+b4lm3GvqjET6gvNY mtwvs2B3LGfyXf9oFx7mnxzVJkcAVOgInsHTwEsn67L7pnG7TWnZN39XPaLgNdN87k+W uvr1lYB3/GtGVy1/NUWK/VuCZvbpbhUeU5evXuOv8GJU5eu2nmv1J+G1Cfq7S/4oahpe /nhyFHRJ94zVk9txmtUIppliBaL2RYMhy/DNK9HrAg/Jbex6mTv/ek0gJ321j0tl04Ve 67Mg== X-Forwarded-Encrypted: i=1; AKwUvBx8s4z3Wf+k4gPiNtLEVV2nEcjl7NQV00Mq9oC9RK7cV/eZcweb0gilzJYHnZRDwPFDgeCpCzg=@vger.kernel.org X-Gm-Message-State: AFq9FYI8a0avlajqWL6C4RbCdVepr7n2egafeyGHsiTst44mLKjYIMT/ wODI3GQ0tsG4YrsXERhdfYETQ0FZa17m7TF/1xRTY57bNP3AKEXkGbU3z5scmBggk44Oog/Q2hS MSMx+w9gWhp6BZp6Ve+72I6TbHkUBpy0OQO0pSVlW7aXIGCbPJnlgW+eQFw== X-Gm-Gg: AYBFou2rGQ4L8S0sWNyAfpI5gRRajJ09A3KQEOZGQ/4S7tL+JyOR42PkA3btwnJnBp7 UuHX0B+8CsuHkSDkutlSZoIrY/PfJ8HsXNdPqaPy5rbDqid3PRyOtbXxwYag+XCpUILrzNDATkt i1J+gyU2XTy96v4CgBg+cAFSoVKTSGtk9aqthPSlCYwcxfDdlu+YpZ1rTabBcefPMY5gRROAV6d y6ZJ3bOmdK/8OX1DQ1oXSKXv5kJSTioXKZ4luBJLtkQecPQH4z8176sYVUa1vqKuG3IMC7l1by1 bTz1c42YtnUdX26+J7ylZzCuBLJdx0fW8it4aW/l/ys0np9LZ/KZ0Pq0YO6koG87AJctUj5dqaM 9KSZQ1PNAWfEH4qZwEaBEcPKGJIlkwqIg0DkUeZhAdmaXfwVE53+Q+sjvx/dF5ovQaRmzhE7eZA == X-Received: by 2002:a5d:5e06:0:b0:48c:69b3:6114 with SMTP id ffacd0b85a97d-48e1e754ca1mr11104928f8f.3.1792571174674; Wed, 21 Oct 2026 01:26:14 -0700 (PDT) X-Received: by 2002:a5d:5e06:0:b0:48c:69b3:6114 with SMTP id ffacd0b85a97d-48e1e754ca1mr11104866f8f.3.1792571174210; Wed, 21 Oct 2026 01:26:14 -0700 (PDT) Received: from [192.168.188.234] (ip232-47-231-195.pool-bba.aruba.it. [195.231.47.232]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e25841b5bsm4076306f8f.47.2026.10.21.01.26.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Oct 2026 01:26:13 -0700 (PDT) Message-ID: <68046007-3737-4f85-bcd1-559daa5835d4@redhat.com> Date: Wed, 21 Oct 2026 10:26:12 +0200 X-Mailing-List: netdev@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v2 1/4] eth: mpnic: count packets, bytes, and drops per ring To: Sebastian Andrzej Siewior , Jakub Kicinski Cc: Daniel Zahka , Alexander Duyck , kernel-team@meta.com, Andrew Lunn , "David S. Miller" , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , Eric Dumazet , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org References: <20261012-mpnic-counters3-v2-0-8afba81c2d5a@gmail.com> <20261012-mpnic-counters3-v2-1-8afba81c2d5a@gmail.com> <20261016220930.i32JEcqe@linutronix.de> <20261019215405.OCzrrKYw@linutronix.de> <20261019190543.419e70bc@kernel.org> <20261020212155.47v0ot4g@linutronix.de> Content-Language: en-US From: Paolo Abeni In-Reply-To: <20261020212155.47v0ot4g@linutronix.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/20/26 23:21, Sebastian Andrzej Siewior wrote: > On 2026-10-19 19:05:43 [-0700], Jakub Kicinski wrote: >> On Mon, 19 Oct 2026 23:54:05 +0200 Sebastian Andrzej Siewior wrote: >>> On 2026-10-19 09:04:38 [-0400], Daniel Zahka wrote: >>>>> Why do you have the two mpnic_base_stats and fold the stats into into >>>>> it? My guess would be that on stop the counters are reset and you want >>>>> to preserve the stats. >>>>> >>>> >>>> Not sure I understand. I think you are asking about two things: >>>> >>>> 1. Why have two mpnic_base_stats? >>>> >>>> To avoid a separate heap allocation that can fail. Handling an >>>> allocation failure in the ndo_stop path when doing the aggregation into >>>> the base stats is tricky. >>> >>> Right. But looking at hinic3_get_stats64() for instance (I just grabbed >>> a random one) it simply does query the stats for each queue, add up, >>> return. It probably does not drop the queues on down, just reallocates >>> them while changing the number of queues (and maybe MTU). >> >> I don't think pre-allocating stats for chips which supports thousands >> of queues is reasonable. > > I don't mean to pre-allocate stats. If device-down removes queues then > the stats gone, so what. The queues could remain. > >>>> 2. Why split stats into base stats and per queue stats, and why reset >>>> the per queue counts when the device transitions down? >>>> >>>> This is the way the stats in netdev.yaml are exposed depending on the >>>> 'scope' request attribute. My reading of the relevant kernel docs is >>>> that the per queue counters are counting events for the current live >>>> queue, so it makes sense to reset them and fold those counts into the >>>> base stats when the interface is transitioned down. >>> >>> Is there any other driver doing this? >>> There is ::get_sset_count() and so on for the per-queue stats. >> >> You may be mixing up queue stats (netlink) with the old ethtool -S >> kitchen sink / garbage dump. > > The statistics is folded on device-down into a global counter. So on > device-up the statistics is still available. At least that is my > understanding. This means the per-queue stats are lost and global stats > don't match the per queue stats anymore. > >>> If the interface goes down and frees all its queues, then the stats are >>> gone, true. But preserving them at the price of two (down+up) forced RCU >>> grace period, I don't know. It looks like a bit too much. >> >> This is a modern driver, the down / up path is not taken when interface >> is reconfigured. It's only taken when the interface is actually taken >> down or bought up. Which virtually never happens for a datacenter NIC. > > So if this never happens, it might not be needed to preserve this. That > force-RCU might not be needed. This does happen on down and I would > assume that the device is no longer processing packets. > >> I don't mean to dismiss your concerns, we agonized over this off-list >> for a week, and don't love the resulting flow, either. But I strongly >> prefer the RCU grace period that never really runs, but is easy to >> reason about, to more advanced fixes which use memory barriers etc. > > Right. If you think is all makes sense and is needed then why not. It > just looks odd. Sebastian, my understanding is that your doubts are mostly because you are unfamiliar with the current reference NIC stats scheme. That has evolved significantly in recent time. I think the approach here is actually quite nice, I don't see blockers. /P