netdev - Re: [RFC net-next 0/4] net: sched: support replay of filter offload when binding to block

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] [day] [month] [year] [list]

Message-ID: <CAJ3xEMiVRR--9Yb--wJa_RKRGobUpCGBg93V1XpK65Gxb-VxDg@mail.gmail.com>
Date:   Wed, 30 May 2018 18:59:39 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     John Hurley <john.hurley@...ronome.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...nulli.us>,
        "Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
        oss-drivers@...ronome.com, Rabie Loulou <rabiel@...lanox.com>
Subject: Re: [RFC net-next 0/4] net: sched: support replay of filter offload
 when binding to block

On Mon, May 28, 2018 at 11:02 PM, Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:
> On Mon, 28 May 2018 13:48:28 +0300, Or Gerlitz wrote:
>> On Fri, May 25, 2018 at 5:25 AM, Jakub Kicinski wrote:
>> > This series from John adds the ability to replay filter offload requests
>> > when new offload callback is being registered on a TC block.  This is most
>> > likely to take place for shared blocks today, when a block which already
>> > has rules is bound to another interface.  Prior to this patch set if any
>> > of the rules were offloaded the block bind would fail.
>>
>> Can you elaborate a little further here? is this something that you are planning
>> to use for the uplink LAG use-case? AFAIU if we apply share-block to nfp as
>> things are prior to this patch, it would work, so there's a case where
>> it doesn't and this is now handled with the series?
>
> Just looking at things as they stand today, no bond/forward looking
> plans - nfp "supports" shared blocks by registering multiple callbacks
> to the block.  There are two problems:
>
> (a) one can't install a second callback if some rules are already
>     offloaded because of:
>
>         /* At this point, playback of previous block cb calls is not supported,
>          * so forbid to register to block which already has some offloaded
>          * filters present.
>          */
>         if (tcf_block_offload_in_use(block))
>                 return ERR_PTR(-EOPNOTSUPP);
>
>     in __tcf_block_cb_register(), so block sharing has to be set up
>     before any rules are added.
>
> (b) when block is unshared filters are not removed today and driver
>     would have to sweep its rule table, as John notes.  It's not a big
>     deal but this series fixes it nicely in the core, too.

OK, thanks for these two point clarifications, much helpful.

> Looking forward there are two things we can use shared blocks for: we
> can try to teach user space to share ingress blocks on all legs of bonds
> instead of trying to propagate the rules from the bond down in the
> kernel, which is more tricky to get right.  We will need reliable
> replay for that, because we want new links to be able to join and leave
> the bond when rules are already present.

> Second use case, which is more far fetched, is trying to discover and
> register callbacks for blocks of tunnel devices directly, and avoid the
> egdev infrastructure...

> We should discuss the above further, but regardless, I think this
> patchset is quite a nice addition on it's own.  Would you agree?

yes, it sounds good, but I need to look deeper, a bit behind on that :(

Or.