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=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,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 2C834C282C4 for ; Sat, 9 Feb 2019 17:39:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DE722206DD for ; Sat, 9 Feb 2019 17:39:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=mojatatu-com.20150623.gappssmtp.com header.i=@mojatatu-com.20150623.gappssmtp.com header.b="vxo/r729" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727166AbfBIRjT (ORCPT ); Sat, 9 Feb 2019 12:39:19 -0500 Received: from mail-it1-f174.google.com ([209.85.166.174]:35051 "EHLO mail-it1-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727081AbfBIRjT (ORCPT ); Sat, 9 Feb 2019 12:39:19 -0500 Received: by mail-it1-f174.google.com with SMTP id r6so16969981itk.0 for ; Sat, 09 Feb 2019 09:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qgFNWmcLPfdBVkwUq7syBGgD/k9niTEVw0R1Cb5KMxo=; b=vxo/r729wzHxTszzZqixKfaQQ2DlsBBweGXEICjZjFy1qU6t/lkUzll5d9MvFV2mRZ 9r9WmjM9mE88g6elXgxfEAb5fGK8cL1/myqWqzc4jZFMP143MaRRmqIhGAVqXEmwLfG+ W8MhBUIKp/0UdMgCc55zjUJB8/sHXRqYHds1w3U4zDug4caHjwG980E/Pk9neby+HkL4 9vJt5DFxPm9Y7hdM22YrdLz2l29z5ECXTH6GIf4NDDUd/mn/X1pORjs6pdPpb4aQiFDh /a/JRMRidPfmsasZaqAxwoE4aLCVma7/sfeHN4pqt6zyq2Lk5ARbNyZucTu+okzlctjG jctw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qgFNWmcLPfdBVkwUq7syBGgD/k9niTEVw0R1Cb5KMxo=; b=bmjSn4/vjND9mFqpoq3zoM872PX66Wgwgd+a7JCPdN03DP98DNIb4Hvi3cGSAl1mBx DQ4KYXzK0mm2lW6CSuUdXaH3zFIEhFS9xwP0abFkzaWuAc+5mR9YakuhJmS09LeQDb9F pQc1xtXSBLw8IvF/lP9tqYinemVYFkYoVnEPCOTkG2v+QKOp8/4flA69X8fRe3Sk+TL5 MvkmhG06B4Xx4stDbbqthbhBuq+dRTVnceZqtBoEgTrCoCVJMU53PN+VRKvcNAVksPQ+ Sfc/HE1rJdlAKFOyGkL6RwwUZCMnVan7htBmJYP3s+H2CNtmXf8cy49cirVmbWu3Dzpy ykUQ== X-Gm-Message-State: AHQUAuYctnYzr7mkLW0m1uCLXSdlMazMo66Op4k61JWDQBVJK/sMwRWr ue3Xuq2z5R4Z2lw9+2fDEoigBdi4yqA= X-Google-Smtp-Source: AHgI3IYORVB+W336EWaTACqNiCn/I8tu6GWh3u0JMKo2SLlp+/FRA8+IjFdm2XENO0aHJx8n0J1l5Q== X-Received: by 2002:a24:5651:: with SMTP id o78mr2111598itb.157.1549733957930; Sat, 09 Feb 2019 09:39:17 -0800 (PST) Received: from [10.0.0.135] (24-212-162-241.cable.teksavvy.com. [24.212.162.241]) by smtp.googlemail.com with ESMTPSA id e1sm1454729itk.38.2019.02.09.09.39.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Feb 2019 09:39:16 -0800 (PST) Subject: Re: TC stats / hw offload question To: Edward Cree , netdev Cc: Jiri Pirko , Cong Wang , Or Gerlitz , Andy Gospodarek , PJ Waskiewicz , Anjali Singhai Jain , Jakub Kicinski References: <26f0cfc9-3bef-8579-72cc-aa6c5ccecd43@solarflare.com> <4cb765dd-453f-3139-bce6-6e0b31167aec@mojatatu.com> <70d77198-42fd-838a-d352-2647e7cad4d6@solarflare.com> From: Jamal Hadi Salim Message-ID: <561205a6-101b-c86b-e77d-6ebdcf31a56d@mojatatu.com> Date: Sat, 9 Feb 2019 12:39:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <70d77198-42fd-838a-d352-2647e7cad4d6@solarflare.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2019-02-08 5:26 a.m., Edward Cree wrote: > On 06/02/19 02:20, Jamal Hadi Salim wrote: >> tc match using flower blah \ >> action vlan push tag ... \ >> action redirect to egress of eth0 >> >> And you submited a packet of size x bytes, >> then the "match" would record x bytes. > > Sorry, where would it record that? Sorry - that was hypothetical on my part. We dont record the bytes in the classifier. We do (on some classifiers) record hit counts, so we can see how many times a lookup on a specific filter happened and how many times that lookup resulted in a match. See u32 (or a few others Cong has been updating recently). >  I can't find any stats counters on >  the "match" either in the software path or the offload API. Hasnt been necessary thus far. Is your end goal to match and count? Most hardware has stats/counters as a separate table. Assuming yours does as well, then if all you want was to just match and accept, then you would add a filter with an accept/ok. i.e something along the lines of: tc match using flower blah \ action ok index 12345 The "action index" field can be used to map to a counter table index in hardware. Note if you dont explicitly specify the index, the kernel (and in this case h/w) issues one for you. >> the "vlan action" would record x bytes. >> the "redirect" would record size x+vlaninfo bytes >> the egress of eth0 would  recorr x+vlaninfo bytes > Am I right in thinking that offloaded counters don't do that?  As far >  as I can tell, the drivers with flower offload all use >  tcf_exts_stats_update() which takes a single 'bytes' count and adds >  it to all the actions.  (Presumably this is pre-edit length.) On the pre/post edit, perhaps some of the hardware owners could chime in +Ccing a few. To the tcf_exts_stats_update(): Note, most people interested in h/w offload will choose to skip sw (explicitly defined when you add a rule). The update synchronizes the hardware stats/counters to the kernel - so when you dump the policies in such a setup you are seeing what is reflected in hardware. cheers, jamal PS: I have to say just keeping one counter is at times insufficient. Example, the policer records how many bytes were seen, not how many bytes were allowed through. For tunnels, it is easy to compute post-edit size because you can easily compute later the added/removed bytes.