Subject: Re: [patch net-next v2 04/10] net: sched: introduce block mechanism to handle netif_keep_dst calls

From: Jiri Pirko <[email-masked]>
Date: Mon, 13 Nov 2017 09:35:55 +0100

Mon, Nov 13, 2017 at 09:17:23AM CET, [email-masked] wrote:
>On Mon, 13 Nov 2017 09:08:16 +0100, Jiri Pirko wrote:
>> Mon, Nov 13, 2017 at 09:03:34AM CET, [email-masked] wrote:
>> >On Mon, 13 Nov 2017 08:58:44 +0100, Jiri Pirko wrote:  
>> >> Mon, Nov 13, 2017 at 08:47:26AM CET, [email-masked] wrote:  
>> >> >On Sun, 12 Nov 2017 16:55:58 +0100, Jiri Pirko wrote:    
>> >> >> From: Jiri Pirko <[email-masked]>
>> >> >> 
>> >> >> 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 <[email-masked]>    
>> >> >
>> >> >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.