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: <20181004101941.509d04b9@cakuba.netronome.com>
Date:   Thu, 4 Oct 2018 10:19:41 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     John Hurley <john.hurley@...ronome.com>
Cc:     Or Gerlitz <gerlitz.or@...il.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, 4 Oct 2018 17:20:43 +0100, John Hurley wrote:
> > > 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.

Right, though nothing stops the driver from registering multiple
callbacks for the same device, if its somehow useful.