netdev - Re: [RFC 0/2] net: sched: indirect/remote setup tc block cb registering

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: <CAK+XE==o9vweQ9+WSUuVdPxKpL5Kw3Mnf47j_BcHpSPmZfESYA@mail.gmail.com>
Date:   Thu, 4 Oct 2018 17:20:43 +0100
From:   John Hurley <john.hurley@...ronome.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...nulli.us>, oss-drivers@...ronome.com,
        ozsh@...lanox.com, avivh@...lanox.com,
        Simon Horman <simon.horman@...ronome.com>
Subject: Re: [RFC 0/2] net: sched: indirect/remote setup tc block cb registering

On Thu, Oct 4, 2018 at 4:53 PM Or Gerlitz <gerlitz.or@...il.com> wrote:
>
> On Thu, Oct 4, 2018 at 6:44 PM John Hurley <john.hurley@...ronome.com> wrote:
> > On Thu, Oct 4, 2018 at 3:28 PM Or Gerlitz <gerlitz.or@...il.com> wrote:
> > > On Thu, Oct 4, 2018 at 7:55 AM Jakub Kicinski <jakub.kicinski@...ronome.com> wrote:
>
> > > > This patchset introduces as an alternative to egdev offload by allowing a
> > > > driver to register for block updates when an external device (e.g. tunnel
> > > > netdev) is bound to a TC block.
>
> > > In a slightly different but hopefully somehow related context, regarding
> > > the case of flow offloading in the presence of upper devices (specifically LAG),
> > > your ovs user patch [1]  applied TC block sharing on the slave of lag (bond/team)
> > > device which serves as ovs port. This way, flows that are installed on
> > > the bond are propagated to both uplink devices - good!
>
> > > However, when tunneling comes into play, the bond device is not part of
> > > the virtual switch but rather the tunnel device, so the SW DP is
> > >
> > > wire --> hw driver --> bond --> stack --> tunnel driver --> virtual switch
> > >
> > > So now, if the HW driver uses your new facility to register for rules installed on the
> > > tunnel device, we are again properly sharing (duplicating) the rules
> > > to both uplinks, right?!
> > >
> > > [1] d22f892 netdev-linux: monitor and offload LAG slaves to TC
>
> > Because the bond is not on the vSwitch, the TC rule will not be
> > offloaded to it and therefore not duplicated to its devices.
>
> indeed
>
> > In this case the hw driver will receive the rules from the tunnel device directly.
> > The driver can then offload them as it sees fit.
>
> if both instances of the hw drivers (uplink0, uplink1) register to get
> the rules installed on the block of the tunnel device we have exactly
> what we want, isn't that?
>

The design here is that each hw driver should only need to register
for callbacks on a 'higher level' device's block once.
When a callback is triggered the driver receives one instance of the
rule and can make its own decision about what to do.
This is slightly different from registering ingress devs where each
uplink registers for its own block.
It is probably more akin to the egdev setup in that if a rule on a
block egresses to an uplink, the driver receives 1 callback on the
rule, irrespective of how may underlying netdevs are on the block.

> > Currently, this setup would be offloaded via egdev.
>
> not following, egdev I thought could be removed... and it's not needed
> as I explained above, unless I miss something?

Apologies - my use of 'currently' meant with the current upstream
kernel (i.e. prior to this patch).