netdev - [RFC PATCH net-next 0/2] RTM

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 29 May 2019 21:07:41 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>, Jiri Pirko <jiri@...nulli.us>,
        "Pablo Neira Ayuso" <pablo@...filter.org>,
        David Miller <davem@...emloft.net>
CC:     netdev <netdev@...r.kernel.org>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Vishal Kulkarni <vishal@...lsio.com>
Subject: [RFC PATCH net-next 0/2] RTM_GETACTION stats offload

Additional patches on top of [v3] flow_offload: Re-add per-action statistics.
Each time we offload a rule to a block, if any hardware offload results
 (in_hw_count), we allocate a binding object for each action, and add it to a
 list on that action (hw_blocks); this is then updated on reoffload and freed
 on destroy.
Then, when handling RTM_GETACTION, just before copying the action stats into
 the netlink response we make a TC_SETUP_ACTION call to each block on the
 hw_blocks list, in tcf_action_update_stats().  The naming is slightly odd as
 tcf_action_update_stats() ends up calling tcf_action_stats_update(), but I
 couldn't think of something less confusing.
Patch #1 adds the machinery and hooks it from cls_flower; I have tested this
 but possibly not explored every possible sequence of events around binding
 and unbinding blocks from actions.
Patch #2 adds the hooks into the other classifiers with offload (matchall,
 u32 and bpf).  I have not tested these at all (except build testing).

There is nothing even remotely resembling an in-tree user of this (hence RFC).
 It does however prove it can be done, and thus that action cookies don't
 restrict our ability to 'fix RTM_GETACTION' once we _do_ have drivers using
 them.

I do somewhat wonder if we could go further, and instead of making, say, a
 TC_CLSFLOWER_STATS callback on a rule, the core could make TC_ACTION_STATS
 calls on each of its actions.  Initially we'd need to keep both callbacks,
 and drivers could choose to implement one or the other (but not both).  And
 of course we could elide the calls when a->ops->stats_update == NULL.
Maybe that's a crazy idea, I don't know.

Edward Cree (2):
  net/sched: add callback to get stats on an action from clsflower
    offload
  net/sched: add action block binding to other classifiers

 include/linux/netdevice.h |  1 +
 include/net/act_api.h     |  2 +-
 include/net/pkt_cls.h     | 18 ++++++++++++++
 net/sched/act_api.c       | 51 +++++++++++++++++++++++++++++++++++++++
 net/sched/cls_bpf.c       | 10 +++++++-
 net/sched/cls_flower.c    |  7 ++++++
 net/sched/cls_matchall.c  |  7 ++++++
 net/sched/cls_u32.c       |  7 ++++++
 8 files changed, 101 insertions(+), 2 deletions(-)