From: Vlad Buslov <vladbu@mellanox.com>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Vlad Buslov <vladbu@mellanox.com>, Jiri Pirko <jiri@resnulli.us>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"xiyou.wangcong@gmail.com" <xiyou.wangcong@gmail.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"mleitner@redhat.com" <mleitner@redhat.com>,
"dcaratti@redhat.com" <dcaratti@redhat.com>,
Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH net-next 00/13] Control action percpu counters allocation by netlink flag
Date: Fri, 25 Oct 2019 14:26:37 +0000 [thread overview]
Message-ID: <vbftv7wuciu.fsf@mellanox.com> (raw)
In-Reply-To: <90c329f6-f2c6-240f-f9c1-70153edd639f@mojatatu.com>
On Thu 24 Oct 2019 at 19:12, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 2019-10-24 11:23 a.m., Vlad Buslov wrote:
>> On Thu 24 Oct 2019 at 10:35, Jiri Pirko <jiri@resnulli.us> wrote:
>>> Wed, Oct 23, 2019 at 04:21:51PM CEST, jhs@mojatatu.com wrote:
>>>> On 2019-10-23 9:04 a.m., Vlad Buslov wrote:
>>>>>
>
> [..]
>>>> Jiri complains constantly about all these new per-action TLVs
>>>> which are generic. He promised to "fix it all" someday. Jiri i notice
>>>> your ack here, what happened? ;->
>>>
>>> Correct, it would be great. However not sure how exactly to do that now.
>>> Do you have some ideas.
>>>
>>>
>>> But basically this patchset does what was done many many times in the
>>> past. I think it was a mistake in the original design not to have some
>>> "common attrs" :/ Lesson learned for next interfaces.
>>
>
> Jiri, we have a high level TLV space which can be applied to all
> actions. See discussion below with Vlad. At least for this specific
> change we can get away from repeating that mistake.
>
>> Jamal, can we reach some conclusion? Do you still suggest to refactor
>> the patches to use TCA_ROOT_FLAGS and parse it in act API instead of
>> individual actions?
>>
>
> IMO this would certainly help us walk away from having
> every action replicate the same attribute with common semantics.
> refactoring ->init() to take an extra attribute may look ugly but
> is cleaner from a uapi pov. Actions that dont implement the feature
> can ignore the extra parameter(s). It doesnt have to be TCA_ROOT_FLAGS
> but certainly that high level TLV space is the right place to put it.
> WDYT?
>
> cheers,
> jamal
Hi Jamal,
I've been trying to re-design this change to use high level TLV, but I
don't understand how to make it backward compatible. If I just put new
attribute before nested action attributes, it will fail to parse when
older client send netlink packet without it and I don't see
straightforward way to distinguish between the new attribute and
following nested action attribute (which might accidentally have same
length and fall into allowed attribute range). I don't have much
experience working with netlink, so I might be missing something obvious
here. However, extending existing action attributes (which are already
conveniently parsed in tcf_action_init_1() function) with new optional
'flags' value seems like straightforward and backward compatible
solution.
Rough outline in code:
2 files changed, 6 insertions(+), 2 deletions(-)
include/uapi/linux/pkt_cls.h | 1 +
net/sched/act_api.c | 7 +++++--
modified include/uapi/linux/pkt_cls.h
@@ -16,6 +16,7 @@ enum {
TCA_ACT_STATS,
TCA_ACT_PAD,
TCA_ACT_COOKIE,
+ TCA_ACT_FLAGS,
__TCA_ACT_MAX
};
modified net/sched/act_api.c
@@ -852,6 +852,7 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
char act_name[IFNAMSIZ];
struct nlattr *tb[TCA_ACT_MAX + 1];
struct nlattr *kind;
+ u32 flags = 0;
int err;
if (name == NULL) {
@@ -877,6 +878,8 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
goto err_out;
}
}
+ if (tb[TCA_ACT_FLAGS])
+ flags = nla_get_bitfield32(tb[TCA_ACT_FLAGS]).value;
} else {
if (strlcpy(act_name, name, IFNAMSIZ) >= IFNAMSIZ) {
NL_SET_ERR_MSG(extack, "TC action name too long");
@@ -915,10 +918,10 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
/* backward compatibility for policer */
if (name == NULL)
err = a_o->init(net, tb[TCA_ACT_OPTIONS], est, &a, ovr, bind,
- rtnl_held, tp, extack);
+ rtnl_held, tp, flags, extack);
else
err = a_o->init(net, nla, est, &a, ovr, bind, rtnl_held,
- tp, extack);
+ tp, flags, extack);
if (err < 0)
goto err_mod;
WDYT?
Regards,
Vlad
next prev parent reply other threads:[~2019-10-25 14:26 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-22 14:17 [PATCH net-next 00/13] Control action percpu counters allocation by netlink flag Vlad Buslov
2019-10-22 14:17 ` [PATCH net-next 01/13] net: sched: extract common action counters update code into function Vlad Buslov
2019-10-22 14:17 ` [PATCH net-next 02/13] net: sched: extract bstats " Vlad Buslov
2019-10-22 14:17 ` [PATCH net-next 03/13] net: sched: extract qstats update code into functions Vlad Buslov
2019-10-22 14:17 ` [PATCH net-next 04/13] net: sched: don't expose action qstats to skb_tc_reinsert() Vlad Buslov
2019-10-22 14:17 ` [PATCH net-next 05/13] net: sched: modify stats helper functions to support regular stats Vlad Buslov
2019-10-22 14:17 ` [PATCH net-next 06/13] net: sched: add action fast initialization flag Vlad Buslov
2019-10-22 14:17 ` [PATCH net-next 07/13] net: sched: act_gact: support fast init flag to skip pcpu allocation Vlad Buslov
2019-10-22 14:17 ` [PATCH net-next 08/13] net: sched: act_csum: " Vlad Buslov
2019-10-22 14:18 ` [PATCH net-next 09/13] net: sched: act_mirred: support fast init flag to skip pcpu alloc Vlad Buslov
2019-10-22 14:18 ` [PATCH net-next 10/13] net: sched: tunnel_key: " Vlad Buslov
2019-10-22 14:18 ` [PATCH net-next 11/13] net: sched: act_vlan: support fast init flag to skip pcpu allocation Vlad Buslov
2019-10-22 14:18 ` [PATCH net-next 12/13] net: sched: act_ct: " Vlad Buslov
2019-10-22 14:18 ` [PATCH net-next 13/13] tc-testing: implement tests for new fast_init action flag Vlad Buslov
2019-10-22 14:28 ` [PATCH iproute2-next] tc: implement support for action flags Vlad Buslov
2019-10-22 14:35 ` [PATCH net-next 00/13] Control action percpu counters allocation by netlink flag Marcelo Ricardo Leitner
2019-10-22 14:52 ` Vlad Buslov
2019-10-22 18:17 ` Roman Mashak
2019-10-23 6:38 ` Vlad Buslov
2019-10-23 13:02 ` Jamal Hadi Salim
2019-10-23 13:08 ` Vlad Buslov
2019-10-22 15:15 ` Marcelo Ricardo Leitner
2019-10-22 15:52 ` Vlad Buslov
2019-10-22 17:09 ` Marcelo Ricardo Leitner
2019-10-23 6:42 ` Vlad Buslov
2019-10-24 15:12 ` Roopa Prabhu
2019-10-24 15:18 ` Vlad Buslov
2019-10-24 17:31 ` Marcelo Ricardo Leitner
2019-10-24 18:03 ` Vlad Buslov
2019-10-23 12:49 ` Jamal Hadi Salim
2019-10-23 13:04 ` Vlad Buslov
2019-10-23 14:21 ` Jamal Hadi Salim
2019-10-23 15:04 ` Vlad Buslov
2019-10-24 7:35 ` Jiri Pirko
2019-10-24 15:23 ` Vlad Buslov
2019-10-24 16:12 ` Jamal Hadi Salim
2019-10-24 16:44 ` Vlad Buslov
2019-10-24 17:17 ` Jamal Hadi Salim
2019-10-24 18:05 ` Vlad Buslov
2019-10-25 11:46 ` Jamal Hadi Salim
2019-10-25 11:55 ` Vlad Buslov
2019-10-25 14:26 ` Vlad Buslov [this message]
2019-10-25 14:57 ` Jamal Hadi Salim
2019-10-25 15:08 ` Jamal Hadi Salim
2019-10-25 15:18 ` Vlad Buslov
2019-10-25 15:43 ` Jamal Hadi Salim
2019-10-25 16:06 ` Jamal Hadi Salim
2019-10-25 16:10 ` Vlad Buslov
2019-10-25 16:29 ` Jamal Hadi Salim
2019-10-25 16:53 ` Vlad Buslov
2019-10-25 18:17 ` Jamal Hadi Salim
2019-10-25 21:05 ` Jamal Hadi Salim
2019-10-25 21:10 ` Jamal Hadi Salim
2019-10-25 21:52 ` Jamal Hadi Salim
2019-10-26 9:44 ` Vlad Buslov
2019-10-26 12:26 ` Jamal Hadi Salim
2019-10-26 14:52 ` Roman Mashak
2019-10-26 16:06 ` Jamal Hadi Salim
2019-10-26 16:42 ` Vlad Buslov
2019-10-26 18:38 ` Jamal Hadi Salim
2019-10-27 8:31 ` Vlad Buslov
2019-10-27 9:13 ` Jamal Hadi Salim
2019-10-25 16:27 ` Vlad Buslov
2019-10-25 16:08 ` Vlad Buslov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vbftv7wuciu.fsf@mellanox.com \
--to=vladbu@mellanox.com \
--cc=davem@davemloft.net \
--cc=dcaratti@redhat.com \
--cc=edumazet@google.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=mleitner@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).