[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201001084152.33cc5bf2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Thu, 1 Oct 2020 08:41:52 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: netdev@...r.kernel.org, andrew@...n.ch, jiri@...nulli.us,
mkubecek@...e.cz, dsahern@...nel.org, pablo@...filter.org
Subject: Re: [RFC net-next 9/9] genetlink: allow dumping command-specific
policy
On Thu, 01 Oct 2020 09:59:47 +0200 Johannes Berg wrote:
> On Wed, 2020-09-30 at 17:05 -0700, Jakub Kicinski wrote:
> > Right now CTRL_CMD_GETPOLICY can only dump the family-wide
> > policy. Support dumping policy of a specific op.
>
> So, hmm.
>
> Yeah, I guess this is fine, but you could end up having to do a lot of
> dumps, and with e.g. ethtool you'd end up with a lot of duplicate data
> too, since it's structured as
>
>
> common_policy = { ... }
>
> cmd1_policy = {
> [CMD1_COMMON] = NLA_NESTED_POLICY(common_policy),
> ...
> };
>
> cmd2_policy = {
> [CMD2_COMMON] = NLA_NESTED_POLICY(common_policy),
> ...
> };
>
> etc.
>
>
> So you end up dumping per command (and in practice, since they can be
> different, you now *have to* unless you know out-of-band that there are
> no per-command policies).
>
>
> Even if I don't have a good idea now on how to avoid the duplication, it
> might be nicer to have a (flag) attribute here for "CTRL_ATTR_ALL_OPS"?
Hm. How would you see the dump structured? We need to annotate the root
policies with the command. Right now I have:
[ATTR_FAMILY_ID]
[ATTR_OP]
[ATTR_POLICY]
[policy idx]
[attr idx]
[bla]
[bla]
[bla]
But if we're dumping _all_ the policy to op mapping is actually 1:n,
so we'd need to restructure the dump a lil' bit and have OP only
reported on root of the policy and make it a nested array.
Alternatively we could report OP -> policy mapping in a separate
message?
WDYT?
Powered by blists - more mailing lists