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]

Date:   Thu, 4 Oct 2018 18:53:43 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     John Hurley <john.hurley@...ronome.com>
Cc:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...nulli.us>, oss-drivers@...ronome.com,
        Oz Shlomo <ozsh@...lanox.com>,
        Aviv Heller <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 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?

> 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?