[{"id":3675342,"web_url":"http://patchwork.ozlabs.org/comment/3675342/","msgid":"","list_archive_url":null,"date":"2026-04-09T13:52:41","subject":"Re: [PATCH RFC net-next 0/4] improve hw flow offload byte accounting","submitter":{"id":1315,"url":"http://patchwork.ozlabs.org/api/people/1315/","name":"Pablo Neira Ayuso","email":"pablo@netfilter.org"},"content":"On Thu, Apr 09, 2026 at 02:07:22PM +0100, Daniel Golle wrote:\n> Hardware flow counters report raw byte counts whose semantics\n> vary by vendor -- some count ingress L2 frames, others egress\n> L2, others L3. The nf_flow_table framework currently passes\n> these bytes straight to conntrack without conversion, and\n> sub-interfaces (VLAN, PPPoE) that are bypassed by hw offload\n> never see any counter updates at all.\n\nI see, but that is part of the feature itself? Why pretend that these\ninterface are really seeing traffic while they don't. This aspiration\nof trying to do all hardware offload fully transparent (when it is not\nthe case, not mentioning semantic changes in how packet handling is\ndone compared to the software plane) does not sound convincing to me.\n\nOn top of this, this issue also exists in the software plane: Devices\nthat are bypasses do not get their counters bumped.\n\nMaybe if this is really a requirement, then this should address the\nissue for software too, but is it worth the effort to add\ninfrastructure for this purpose?\n\n> This series lets drivers declare what their counters represent,\n> so the framework can normalize to L3 for conntrack and\n> propagate per-layer stats to encap sub-interfaces.\n> \n> Questions:\n> - Sub-interface stats accesses vlan_dev_priv() directly --\n> should there be a generic netdev callback instead?\n> - Are there hw offload drivers whose counters do not fit the\n> ingress-L2 / egress-L2 / L3 model?\n> \n> Daniel Golle (4):\n> net: flow_offload: let drivers report byte counter semantics\n> nf_flow_table: track sub-interface and bridge ifindex in flow tuple\n> nf_flow_table: convert hw byte counts and update sub-interface stats\n> net: ethernet: mtk_eth_soc: report INGRESS_L2 byte_type in flow stats\n> \n> .../net/ethernet/mediatek/mtk_ppe_offload.c | 1 +\n> include/net/flow_offload.h | 7 +\n> include/net/netfilter/nf_flow_table.h | 5 +\n> net/netfilter/nf_flow_table_core.c | 2 +\n> net/netfilter/nf_flow_table_offload.c | 174 +++++++++++++++++-\n> net/netfilter/nf_flow_table_path.c | 8 +\n> 6 files changed, 195 insertions(+), 2 deletions(-)\n> \n> -- \n> 2.53.0","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","netfilter-devel@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=netfilter.org header.i=@netfilter.org\n header.a=rsa-sha256 header.s=2025 header.b=NdyAj/K3;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11769-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=netfilter.org header.i=@netfilter.org\n header.b=\"NdyAj/K3\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=217.70.190.124","smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=netfilter.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=netfilter.org"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fs1nC05kJz1yCv\n\tfor ; Fri, 10 Apr 2026 00:01:19 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 83CD630D3EEC\n\tfor ; Thu, 9 Apr 2026 13:54:07 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 549433D648F;\n\tThu, 9 Apr 2026 13:52:49 +0000 (UTC)","from mail.netfilter.org (mail.netfilter.org [217.70.190.124])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id CA4D73D646A;\n\tThu, 9 Apr 2026 13:52:46 +0000 (UTC)","from netfilter.org (mail-agni [217.70.190.124])\n\tby mail.netfilter.org (Postfix) with UTF8SMTPSA id 23EDC60179;\n\tThu, 9 Apr 2026 15:52:44 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775742768; cv=none;\n b=Q38ul4KHsJzl4oSihY0zisC0ZWsQ4MdzIEg1nFaeGihCCK544U6w/kSXW0x57DjJ8xs2n1Ln8ndIz8at5IVHO08nYdA1AZB5JT/B8oKwwb9PdG00TnbZlhgfM01mNUpK2q24yniHQZv76IIN7Q4x4NYHgtXiwsAcbt5zrUVpt8U=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775742768; c=relaxed/simple;\n\tbh=22bWjfBPSJNqnW3obSFGY+DfmkXrKL/eqvH4q6bKYtw=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=Jm/vaDli/YK3OGSnS7pPI1IBtXt+QEIqnqTec0UGki59L0GP6I87nXQGNzR6aSZBjPopzK9fHMvmboIp+wcSoqz1onXeR8Jlqb+Buc6h+g4gMb5kdItlnK14aAo0xuZpM+F8n6bWfemvG6NXqCGgIEb+LlcAsKjow/ciuA7jESM=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=netfilter.org;\n spf=pass smtp.mailfrom=netfilter.org;\n dkim=pass (2048-bit key) header.d=netfilter.org header.i=@netfilter.org\n header.b=NdyAj/K3; arc=none smtp.client-ip=217.70.190.124","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=netfilter.org;\n\ts=2025; t=1775742764;\n\tbh=24hA1l9NAmNo3LU0r4Q8hfjssSJC6vwBl2Dt0Dwe1A4=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=NdyAj/K3A2fPx/giXVVKQfyeH1WrYGjmd5lMbaoH1QqoyrngAHcQzJ3fRY/9OoY1A\n\t NjZ6OQLJnbvbkIOfUfmcyapser63R/ikzngMBy2uW/5y45Zh3PNUUcVWIyhtNJdlIO\n\t BDcFCa5yWR1P01MYbLfQgaBmyr49Ai8Iz9nPqwuuw5ARrwxQ6LhMv+FCWUtQX8zSrr\n\t aSY7vcjWtGcJ/BCtwkDNumkVzR7KzNlcAyi9gPan7X+vn0zG4aXjXkcDin0MeXZe6+\n\t ZCGJSK4iUmtZMnfkXlRBA1texNhTbl4s2z7GndweiSlFXJfrHzWsBco+zErMdXGCP+\n\t RDDEAuVznrUMg==","Date":"Thu, 9 Apr 2026 15:52:41 +0200","From":"Pablo Neira Ayuso ","To":"Daniel Golle ","Cc":"Felix Fietkau , John Crispin ,\n\tLorenzo Bianconi ,\n\tAndrew Lunn ,\n\t\"David S. Miller\" ,\n\tEric Dumazet ,\n\tJakub Kicinski , Paolo Abeni ,\n\tMatthias Brugger ,\n\tAngeloGioacchino Del Regno ,\n\tSimon Horman , Florian Westphal ,\n\tPhil Sutter , netdev@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tlinux-mediatek@lists.infradead.org, netfilter-devel@vger.kernel.org,\n\tcoreteam@netfilter.org","Subject":"Re: [PATCH RFC net-next 0/4] improve hw flow offload byte accounting","Message-ID":"","References":"","Precedence":"bulk","X-Mailing-List":"netfilter-devel@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":""}},{"id":3675351,"web_url":"http://patchwork.ozlabs.org/comment/3675351/","msgid":"","list_archive_url":null,"date":"2026-04-09T14:21:45","subject":"Re: [PATCH RFC net-next 0/4] improve hw flow offload byte accounting","submitter":{"id":64091,"url":"http://patchwork.ozlabs.org/api/people/64091/","name":"Daniel Golle","email":"daniel@makrotopia.org"},"content":"On Thu, Apr 09, 2026 at 03:52:41PM +0200, Pablo Neira Ayuso wrote:\n> On Thu, Apr 09, 2026 at 02:07:22PM +0100, Daniel Golle wrote:\n> > Hardware flow counters report raw byte counts whose semantics\n> > vary by vendor -- some count ingress L2 frames, others egress\n> > L2, others L3. The nf_flow_table framework currently passes\n> > these bytes straight to conntrack without conversion, and\n> > sub-interfaces (VLAN, PPPoE) that are bypassed by hw offload\n> > never see any counter updates at all.\n> \n> I see, but that is part of the feature itself? Why pretend that these\n> interface are really seeing traffic while they don't. This aspiration\n> of trying to do all hardware offload fully transparent (when it is not\n> the case, not mentioning semantic changes in how packet handling is\n> done compared to the software plane) does not sound convincing to me.\n\nPlease explain what you mean by offloading not being fully\ntransparent. If the MAC hardware offloads VLAN encap/decap, for\nexample, we also maintain the counters correctly (it just so happens),\njust the flow-offloading case results in a weird overall picture:\nhardware interface counters keep increasing, encap interfaces (802.1Q,\nPPPoE) don't. That makes it confusing and hard to understand what's\nhappening when only looking at the interface counters (ie. \"what is\nall that traffic on my physical WAN interface which isn't PPPoE? Can't\nbe that all of that is the modems management interface, SNMP, ...\")\n\n> \n> On top of this, this issue also exists in the software plane: Devices\n> that are bypasses do not get their counters bumped.\n> \n> Maybe if this is really a requirement, then this should address the\n> issue for software too, but is it worth the effort to add\n> infrastructure for this purpose?\n\nTo me it would feel more correct to see counters increasing also\nfor offloaded traffic on software interfaces such as PPPoE or VLAN.\n\nI honestly didn't think about the software fastpath, and yes, I think\nit should be addressed there too.\n\n> > This series lets drivers declare what their counters represent,\n> > so the framework can normalize to L3 for conntrack and\n> > propagate per-layer stats to encap sub-interfaces.\n\nThis part could also been seen as an independent fix as currently\nconntrack stats for the same traffic differ in case of software\noffloading (pure L3 bytes) and hardware offloading (L2 ingress bytes\nin case of mtk_ppe).","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","netfilter-devel@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11772-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=185.142.180.65","smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=makrotopia.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=makrotopia.org"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fs2N350W3z1yD3\n\tfor ; Fri, 10 Apr 2026 00:28:03 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id A70033096F90\n\tfor ; Thu, 9 Apr 2026 14:22:13 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id CE33A3DC4A3;\n\tThu, 9 Apr 2026 14:22:01 +0000 (UTC)","from pidgin.makrotopia.org (pidgin.makrotopia.org [185.142.180.65])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F8B03DA7E0;\n\tThu, 9 Apr 2026 14:21:59 +0000 (UTC)","from local\n\tby pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256)\n\t (Exim 4.99)\n\t(envelope-from )\n\tid 1wAqGT-000000002Iq-2EUP;\n\tThu, 09 Apr 2026 14:21:49 +0000"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775744521; cv=none;\n b=oho68U9mmS/ouVeo47cq6zc71kdkd/oV+Z29xI2l1d0mq9IM1+XrH8Wa8pjIDmc8Xg09G16clUSSA63B93sI7PYqzPnMVwFEaHdt0F3xuFByfGexLLIzJELBAXmjbdsVaEvw1hVNNz/ZQIZFhmF+LKUsTRO6tI1LGkjn0mc+KA0=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775744521; c=relaxed/simple;\n\tbh=hgBEqVyt53AXPKU+9AYIC3cphVx6joVQQ0wDtlqImKY=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=dV2gF+nP+RcWyNaNwDEqzustMRXzmK25hC09fYnAdI23030rRr9cTd+mio7tJ5afcWk0FVOoxnHW+qbXDn7k/TcvqjfMbbqKGt2I845Tf3+SvISxWd02IiIvYb1QPCBrhR2xL7X3aCmiLSxRILCxxJb1cgeXJXhZtzyrBnY4RrA=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=makrotopia.org;\n spf=pass smtp.mailfrom=makrotopia.org; arc=none smtp.client-ip=185.142.180.65","Date":"Thu, 9 Apr 2026 15:21:45 +0100","From":"Daniel Golle ","To":"Pablo Neira Ayuso ","Cc":"Felix Fietkau , John Crispin ,\n\tLorenzo Bianconi ,\n\tAndrew Lunn ,\n\t\"David S. Miller\" ,\n\tEric Dumazet ,\n\tJakub Kicinski , Paolo Abeni ,\n\tMatthias Brugger ,\n\tAngeloGioacchino Del Regno ,\n\tSimon Horman , Florian Westphal ,\n\tPhil Sutter , netdev@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tlinux-mediatek@lists.infradead.org, netfilter-devel@vger.kernel.org,\n\tcoreteam@netfilter.org","Subject":"Re: [PATCH RFC net-next 0/4] improve hw flow offload byte accounting","Message-ID":"","References":"\n ","Precedence":"bulk","X-Mailing-List":"netfilter-devel@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":""}}]