From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4325C282CB for ; Tue, 5 Feb 2019 19:41:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8919C217D6 for ; Tue, 5 Feb 2019 19:41:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729532AbfBETlZ (ORCPT ); Tue, 5 Feb 2019 14:41:25 -0500 Received: from dispatch1-us1.ppe-hosted.com ([148.163.129.52]:50928 "EHLO dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729387AbfBETlZ (ORCPT ); Tue, 5 Feb 2019 14:41:25 -0500 X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id EFAEC1000C5; Tue, 5 Feb 2019 19:41:17 +0000 (UTC) Received: from ec-desktop.uk.solarflarecom.com (10.17.20.45) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Feb 2019 11:41:13 -0800 To: netdev CC: Jiri Pirko , Jamal Hadi Salim , "Cong Wang" From: Edward Cree Subject: TC stats / hw offload question Message-ID: <26f0cfc9-3bef-8579-72cc-aa6c5ccecd43@solarflare.com> Date: Tue, 5 Feb 2019 19:41:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [10.17.20.45] X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24410.005 X-TM-AS-Result: No-0.362600-4.000000-10 X-TMASE-MatchedRID: UHN19ZU8rvlFsw2Lp+kSuKMVgdN9w+TCf6/Md8Lb2l8fkuHQlxj2aGM9 4EcycNIwxXP6p7fFEhngqtcrFIAcc49oUcx9VMLggxsfzkNRlfJjFT88f69nG/oLR4+zsDTt9xS 3mVzWUuAojN1lLei7RY38FFBXUK6D3fzu6TFJFhVnp1hDATV3S2gCZY8TpEBd+42hwGDXbDbrti 627t+vQaL3J8Bo/n9YvPYWVs7ix1nMJeHJK86YG+RS1bO54BEDxmFfvo297gQGQTk2UTvzG4hRS ajoE6U5 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--0.362600-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24410.005 X-MDID: 1549395682-lW147scTwDBe Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Regarding TC_CLSFLOWER_STATS, when a filter rule modifies the length of  the packet, e.g. by adding a VLAN or encap header, should the bytes  counter count the length of the packet _before_ edits (i.e. as seen by  the match), or the length after edits?  If the latter, what is the  correct behaviour when (say) a packet is mirrored as-is but also  redirected with encapsulation? The fact that the stats live in the struct tc_action suggests a per-  action connection that would imply post-edit length, but then in  tcf_exts_dump_stats() we only look at the first action, which seems to  imply we really want the pre-edit length. I can't find any kind of doc or spec defining what behaviour is required. -Ed