netdev - Re: [patch net-next v2 04/10] net: sched: introduce block mechanism to handle netif_keep

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: <20171113083555.GJ1986@nanopsycho>
Date:   Mon, 13 Nov 2017 09:35:55 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, jhs@...atatu.com,
        xiyou.wangcong@...il.com, mlxsw@...lanox.com, andrew@...n.ch,
        vivien.didelot@...oirfairelinux.com, f.fainelli@...il.com,
        ast@...nel.org, daniel@...earbox.net, simon.horman@...ronome.com,
        pieter.jansenvanvuuren@...ronome.com, john.hurley@...ronome.com
Subject: Re: [patch net-next v2 04/10] net: sched: introduce block mechanism
 to handle netif_keep_dst calls

Mon, Nov 13, 2017 at 09:17:23AM CET, jakub.kicinski@...ronome.com wrote:
>On Mon, 13 Nov 2017 09:08:16 +0100, Jiri Pirko wrote:
>> Mon, Nov 13, 2017 at 09:03:34AM CET, jakub.kicinski@...ronome.com wrote:
>> >On Mon, 13 Nov 2017 08:58:44 +0100, Jiri Pirko wrote:  
>> >> Mon, Nov 13, 2017 at 08:47:26AM CET, jakub.kicinski@...ronome.com wrote:  
>> >> >On Sun, 12 Nov 2017 16:55:58 +0100, Jiri Pirko wrote:    
>> >> >> From: Jiri Pirko <jiri@...lanox.com>
>> >> >> 
>> >> >> Couple of classifiers call netif_keep_dst directly on q->dev. That is
>> >> >> not possible to do directly for shared blocke where multiple qdiscs are
>> >> >> owning the block. So introduce a infrastructure to keep track of the
>> >> >> block owners in list and use this list to implement block variant of
>> >> >> netif_keep_dst.
>> >> >> 
>> >> >> Signed-off-by: Jiri Pirko <jiri@...lanox.com>    
>> >> >
>> >> >Could you use the list you add here to check the ethtool tc offload
>> >> >flag? :)    
>> >> 
>> >> It is a list of qdisc sub parts. Not a list of netdevs  
>> >
>> >Hm.  OK, I won't pretend I understand the TC code in detail, I thought
>> >that would give you all netdevs, but possibly duplicated.  
>> 
>> Yeah, eventually you can get it. But still, it is unusable to check the
>> offload flag cause it has no relation with the block cbs.
>
>OK.  Depends on which flags you intend to check.  I.e. is it OK to
>offload filters of the bond, because all its slaves have offloads on
>but the bond itself doesn't.  Is that what you mean?

No.
What I mean is, there is not always 1:1 relation between a registered
block cb and netdev. For example in case of mlxsw. When multiple mlxsw
devices share the same block, there is only one block cb call for all
of them.