netdev - Re: [RFC net-next 2/6] driver: net: bonding: allow registration of tc offload callbacks in bond

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: <20180307105727.GC2144@nanopsycho>
Date:   Wed, 7 Mar 2018 11:57:27 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     John Hurley <john.hurley@...ronome.com>
Cc:     netdev@...r.kernel.org, jiri@...lanox.com, ogerlitz@...lanox.com,
        jakub.kicinski@...ronome.com, simon.horman@...ronome.com
Subject: Re: [RFC net-next 2/6] driver: net: bonding: allow registration of
 tc offload callbacks in bond

Mon, Mar 05, 2018 at 02:28:30PM CET, john.hurley@...ronome.com wrote:
>Allow drivers to register netdev callbacks for tc offload in linux bonds.
>If a netdev has registered and is a slave of a given bond, then any tc
>rules offloaded to the bond will be relayed to it if both the bond and the
>slave permit hw offload.
>
>Because the bond itself is not offloaded, just the rules, we don't care
>about whether the bond ports are on the same device or whether some of
>slaves are representor ports and some are not.
>
>Signed-off-by: John Hurley <john.hurley@...ronome.com>
>---
> drivers/net/bonding/bond_main.c | 195 +++++++++++++++++++++++++++++++++++++++-
> include/net/bonding.h           |   7 ++
> 2 files changed, 201 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index e6415f6..d9e41cf 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c

[...]


>+EXPORT_SYMBOL_GPL(tc_setup_cb_bond_register);

Please, no "bond" specific calls from drivers. That would be wrong.
The idea behing block callbacks was that anyone who is interested could
register to receive those. In this case, slave device is interested.
So it should register to receive block callbacks in the same way as if
the block was directly on top of the slave device. The only thing you
need to handle is to propagate block bind/unbind from master down to the
slaves.