Mon, Nov 13, 2017 at 09:17:23AM CET, jakub.kicin...@netronome.com wrote: >On Mon, 13 Nov 2017 09:08:16 +0100, Jiri Pirko wrote: >> Mon, Nov 13, 2017 at 09:03:34AM CET, jakub.kicin...@netronome.com wrote: >> >On Mon, 13 Nov 2017 08:58:44 +0100, Jiri Pirko wrote: >> >> Mon, Nov 13, 2017 at 08:47:26AM CET, jakub.kicin...@netronome.com wrote: >> >> >On Sun, 12 Nov 2017 16:55:58 +0100, Jiri Pirko wrote: >> >> >> From: Jiri Pirko <j...@mellanox.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 <j...@mellanox.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.
