Mon, Nov 13, 2017 at 09:45:12AM CET, jakub.kicin...@netronome.com wrote: >On Mon, 13 Nov 2017 09:35:55 +0100, Jiri Pirko wrote: >> 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. > >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.
