netdev - Re: [PATCH net-next 00/12] netfilter: add hardware offload infrastructure

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:   Fri, 21 Jun 2019 17:16:40 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
        davem@...emloft.net, thomas.lendacky@....com, f.fainelli@...il.com,
        ariel.elior@...ium.com, michael.chan@...adcom.com,
        santosh@...lsio.com, madalin.bucur@....com,
        yisen.zhuang@...wei.com, salil.mehta@...wei.com,
        jeffrey.t.kirsher@...el.com, tariqt@...lanox.com,
        saeedm@...lanox.com, jiri@...lanox.com, idosch@...lanox.com,
        jakub.kicinski@...ronome.com, peppe.cavallaro@...com,
        grygorii.strashko@...com, andrew@...n.ch,
        vivien.didelot@...oirfairelinux.com, alexandre.torgue@...com,
        joabreu@...opsys.com, linux-net-drivers@...arflare.com,
        ganeshgr@...lsio.com, ogerlitz@...lanox.com,
        Manish.Chopra@...ium.com, marcelo.leitner@...il.com,
        mkubecek@...e.cz, venkatkumar.duvvuru@...adcom.com,
        cphealy@...il.com
Subject: Re: [PATCH net-next 00/12] netfilter: add hardware offload
 infrastructure

Thu, Jun 20, 2019 at 09:49:05PM CEST, pablo@...filter.org wrote:
>Hi,
>
>This patchset adds support for Netfilter hardware offloads.
>
>This patchset reuses the existing block infrastructure, the
>netdev_ops->ndo_setup_tc() interface, TC_SETUP_CLSFLOWER classifier and
>the flow rule API.
>
>Patch #1 moves tcf_block_cb code before the indirect block
>	 infrastructure to avoid forward declarations in the next
>	 patches. This is just a preparation patch.
>
>Patch #2 adds tcf_block_cb_alloc() to allocate flow block callbacks.
>
>Patch #3 adds tcf_block_cb_free() to release flow block callbacks.
>
>Patch #4 adds the tcf_block_setup() infrastructure, which allows drivers
>         to set up flow block callbacks. This infrastructure transports
>         these objects via list (through the tc_block_offload object)
>	 back to the core for registration.
>
>            CLS_API                           DRIVER
>        TC_SETUP_BLOCK    ---------->  setup flow_block_cb object &
>                                 it adds object to flow_block_offload->cb_list
>                                                |
>            CLS_API     <-----------------------'
>           registers                     list if flow block
>         flow_block_cb &                   travels back to
>       calls ->reoffload               the core for registration
>
>Patch #5 extends tcf_block_cb_alloc() to allow drivers to set a release
>	 callback that is invoked from tcf_block_cb_free() to release
>         private driver block information.
>
>Patch #6 adds tcf_setup_block_offload(), this helper function is used by
>         most drivers to setup the block, including common bind and
>         unbind operations.
>
>Patch #7 adapts drivers to use the infrastructure introduced in Patch #4.
>
>Patch #8 stops exposing the tc block structure to drivers, by caching
>	 the only information that drivers need, ie. block is shared
>	 flag.
>
>Patch #9 removes the tcf_block_cb_register() / _unregister()
>	 infrastructure, since it is now unused after Patch #7.
>
>Patch #10 moves the flow_block API to the net/core/flow_offload.c core.
>          This renames tcf_block_cb to flow_block_cb as well as the
>	  functions to allocate, release, lookup and setup flow block
>	  callbacks.
>
>Patch #11 makes sure that only one flow block callback per device is
>          possible by now. This means only one of the ethtool / tc /
>          netfilter subsystems can use hardware offloads, until drivers
>	  are updated to remove this limitation.
>
>Patch #12 introduces basic netfilter hardware offload infrastructure
>	  for the ingress chain. This includes 5-tuple matching and
>          accept / drop actions. Only basechains are supported at this
>          stage, no .reoffload callback is implemented either.
>
>Please, apply, thanks.


Please add some examples of usage here and in the last patch (duplicated
text). Thanks!