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: <20171113085420.GK1986@nanopsycho>
Date:   Mon, 13 Nov 2017 09:54:20 +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:45:12AM CET, jakub.kicinski@...ronome.com wrote:
>On Mon, 13 Nov 2017 09:35:55 +0100, Jiri Pirko wrote:
>> 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.
>
>OK, I'm clearly missing something.  I would have thought that the case
>where the callback is shared for multiple port netdevs is pretty well
>covered by the Qdiscs owning the block, provided that you said you
>intend to only offload the rule if all port netdevs sharing the block
>have the TC offload on.

You are right. But still, how do you map the qdiscs owning the block to
whoever who registers the cb? That is my point.