netdev - Re: [RFC PATCH net-next 2/3] flow_offload: restore ability to collect separate stats per action

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190507102253.37b6681d@cakuba.hsd1.ca.comcast.net>
Date:   Tue, 7 May 2019 10:22:53 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>, Jiri Pirko <jiri@...nulli.us>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        "Cong Wang" <xiyou.wangcong@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        Anjali Singhai Jain <anjali.singhai@...el.com>,
        Or Gerlitz <gerlitz.or@...il.com>
Subject: Re: [RFC PATCH net-next 2/3] flow_offload: restore ability to
 collect separate stats per action

On Tue, 7 May 2019 13:27:15 +0100, Edward Cree wrote:
> On 06/05/2019 13:41, Jamal Hadi Salim wrote:
> > On 2019-05-04 2:27 a.m., Jakub Kicinski wrote:  
> >> On Fri, 3 May 2019 16:06:55 +0100, Edward Cree wrote:  
> >>> Introduce a new offload command TC_CLSFLOWER_STATS_BYINDEX, similar to
> >>>   the existing TC_CLSFLOWER_STATS but specifying an action_index (the
> >>>   tcfa_index of the action), which is called for each stats-having action
> >>>   on the rule.  Drivers should implement either, but not both, of these
> >>>   commands.  
> >>
> >> It feels a little strange to me to call the new stats updates from
> >> cls_flower, if we really want to support action sharing correctly.
> >>
> >> Can RTM_GETACTION not be used to dump actions without dumping the
> >> classifiers?  If we dump from the classifiers wouldn't that lead to
> >> stale stats being returned?  
> >
> > Not sure about the staleness factor, but:
> > For efficiency reasons we certainly need the RTM_GETACTION approach
> > (as you stated above we dont need to dump all that classifier info if
> > all we want are stats). This becomes a big deal if you have a lot
> > of stats/rules.  
> 
> I don't know much of anything about RTM_GETACTION, but it doesn't appear
>  to be part of the current "tc offload" world, which AIUI is very much
>  centred around cls_flower.  I'm just trying to make counters in
>  cls_flower offload do 'the right thing' (whatever that may be), anything
>  else is out of scope.

I understand, and you are correct that the action sharing is not part
of the current "tc offload" world.  My point is that you are making it
part of the offload world, so it'd be best if it could be done well
from the start.

People trying to make the code do the right thing just in their narrow
use case brings us the periodic rewrites of the TC offload
infrastructure, and every time we do it some use cases get broken :/