netdev - Re: [RFC net-next 0/6] offload linux bonding tc ingress rules

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: <CAJieiUhEdHFa7zYN6pEg==OcR0H7-LNBkL15XAMdSqG0cFxZOg@mail.gmail.com>
Date:   Mon, 5 Mar 2018 18:34:10 -0800
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     John Hurley <john.hurley@...ronome.com>, netdev@...r.kernel.org,
        Jiri Pirko <jiri@...lanox.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Simon Horman <simon.horman@...ronome.com>
Subject: Re: [RFC net-next 0/6] offload linux bonding tc ingress rules

On Mon, Mar 5, 2018 at 2:08 PM, Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:
> On Mon,  5 Mar 2018 13:28:28 +0000, John Hurley wrote:
>> The linux bond itself registers a cb for offloading tc rules. Potential
>> slave netdevs on offload devices can then register with the bond for a
>> further callback - this code is basically the same as registering for an
>> egress dev offload in TC. Then when a rule is offloaded to the bond, it
>> can be relayed to each netdev that has registered with the bond code and
>> which is a slave of the given bond.
>
> As you know I would much rather see this handled in the TC core,
> similarly to how blocks are shared.  We can add a new .ndo_setup_tc
> notification like TC_MASTER_BLOCK_BIND and reuse the existing offload
> tracking.  It would also fix the problem of freezing the bond and allow
> better code reuse with team etc.

+1 to handle this in tc core. We will soon find that many other
devices will need to propagate rules down
 the netdev stack and keeping it in tc core allows re-use like you state above.
The switchdev api's before they moved to notifiers in many cases had
bond and other netdev stack offload
traversal inside the switchdev layer (In the notifier world, I think a
driver can still register and track rules and other offload on
 bonds with its own ports as slaves)