From: Jakub Kicinski <kuba@kernel.org>
To: Petr Machata <petrm@mellanox.com>
Cc: netdev@vger.kernel.org, Roman Mashak <mrv@mojatatu.com>,
jhs@mojatatu.com, xiyou.wangcong@gmail.com, davem@davemloft.net,
jiri@mellanox.com, mlxsw@mellanox.com
Subject: Re: [PATCH net-next v2 2/6] net: sched: Allow extending set of supported RED flags
Date: Wed, 11 Mar 2020 15:09:20 -0700 [thread overview]
Message-ID: <20200311150920.306de7c6@kicinski-fedora-PC1C0HJN> (raw)
In-Reply-To: <20200311173356.38181-3-petrm@mellanox.com>
On Wed, 11 Mar 2020 19:33:52 +0200 Petr Machata wrote:
> diff --git a/include/net/red.h b/include/net/red.h
> index 9665582c4687..5718d2b25637 100644
> --- a/include/net/red.h
> +++ b/include/net/red.h
> @@ -179,6 +179,31 @@ static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog)
> return true;
> }
>
> +static inline bool red_get_flags(unsigned char flags,
> + unsigned char historic_mask,
> + struct nlattr *flags_attr,
> + unsigned int supported_mask,
> + unsigned int *p_flags, unsigned char *p_userbits,
> + struct netlink_ext_ack *extack)
> +{
> + if (flags && flags_attr) {
> + NL_SET_ERR_MSG_MOD(extack, "flags should be passed either through qopt, or through a dedicated attribute");
> + return false;
> + }
> +
> + *p_flags = flags & historic_mask;
> + if (flags_attr)
> + *p_flags |= nla_get_u32(flags_attr);
It's less error prone for callers not to modify the output parameters
until we're sure the call won't fail.
> + if (*p_flags & ~supported_mask) {
> + NL_SET_ERR_MSG_MOD(extack, "unsupported RED flags specified");
> + return false;
> + }
> +
> + *p_userbits = flags & ~historic_mask;
> + return true;
> +}
> +
> +#define TC_RED_HISTORIC_FLAGS (TC_RED_ECN | TC_RED_HARDDROP | TC_RED_ADAPTATIVE)
> +
> struct tc_red_xstats {
> __u32 early; /* Early drops */
> __u32 pdrop; /* Drops due to queue limits */
> diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c
> index 1695421333e3..61d7c5a61279 100644
> --- a/net/sched/sch_red.c
> +++ b/net/sched/sch_red.c
> @@ -35,7 +35,11 @@
>
> struct red_sched_data {
> u32 limit; /* HARD maximal queue length */
> - unsigned char flags;
> +
> + u32 flags;
Can we stick to uchar until the number of flags grows?
> + /* Non-flags in tc_red_qopt.flags. */
> + unsigned char userbits;
> +
> struct timer_list adapt_timer;
> struct Qdisc *sch;
> struct red_parms parms;
> @@ -44,6 +48,8 @@ struct red_sched_data {
> struct Qdisc *qdisc;
> };
>
> +#define RED_SUPPORTED_FLAGS TC_RED_HISTORIC_FLAGS
> +
> static inline int red_use_ecn(struct red_sched_data *q)
> {
> return q->flags & TC_RED_ECN;
> @@ -186,6 +192,7 @@ static const struct nla_policy red_policy[TCA_RED_MAX + 1] = {
> [TCA_RED_PARMS] = { .len = sizeof(struct tc_red_qopt) },
> [TCA_RED_STAB] = { .len = RED_STAB_SIZE },
> [TCA_RED_MAX_P] = { .type = NLA_U32 },
> + [TCA_RED_FLAGS] = { .type = NLA_U32 },
BITFIELD32? And then perhaps turn the define into a const validation
data?
Also policy needs a .strict_start_type now.
> };
>
> static int red_change(struct Qdisc *sch, struct nlattr *opt,
> @@ -302,7 +317,8 @@ static int red_dump(struct Qdisc *sch, struct sk_buff *skb)
> struct nlattr *opts = NULL;
> struct tc_red_qopt opt = {
> .limit = q->limit,
> - .flags = q->flags,
> + .flags = ((q->flags & TC_RED_HISTORIC_FLAGS) |
> + q->userbits),
nit: parens unnecessary
> .qth_min = q->parms.qth_min >> q->parms.Wlog,
> .qth_max = q->parms.qth_max >> q->parms.Wlog,
> .Wlog = q->parms.Wlog,
> @@ -321,6 +337,8 @@ static int red_dump(struct Qdisc *sch, struct sk_buff *skb)
> if (nla_put(skb, TCA_RED_PARMS, sizeof(opt), &opt) ||
> nla_put_u32(skb, TCA_RED_MAX_P, q->parms.max_P))
> goto nla_put_failure;
> + if (q->flags & ~TC_RED_HISTORIC_FLAGS)
> + nla_put_u32(skb, TCA_RED_FLAGS, q->flags);
Not 100% sure if conditional is needed, but please check the return
code.
> return nla_nest_end(skb, opts);
>
> nla_put_failure:
next prev parent reply other threads:[~2020-03-11 22:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-11 17:33 [PATCH net-next v2 0/6] RED: Introduce an ECN tail-dropping mode Petr Machata
2020-03-11 17:33 ` [PATCH net-next v2 1/6] selftests: qdiscs: Add TDC test for RED Petr Machata
2020-03-12 2:20 ` Roman Mashak
2020-03-11 17:33 ` [PATCH net-next v2 2/6] net: sched: Allow extending set of supported RED flags Petr Machata
2020-03-11 22:09 ` Jakub Kicinski [this message]
2020-03-12 0:12 ` Petr Machata
2020-03-11 17:33 ` [PATCH net-next v2 3/6] net: sched: RED: Introduce an ECN tail-dropping mode Petr Machata
2020-03-11 18:36 ` Eric Dumazet
2020-03-12 0:42 ` Petr Machata
2020-03-12 1:01 ` Eric Dumazet
2020-03-12 2:25 ` Jakub Kicinski
2020-03-12 10:16 ` Petr Machata
2020-03-12 10:17 ` Petr Machata
2020-03-11 17:33 ` [PATCH net-next v2 4/6] mlxsw: spectrum_qdisc: Offload RED " Petr Machata
2020-03-11 17:33 ` [PATCH net-next v2 5/6] selftests: qdiscs: RED: Add taildrop tests Petr Machata
2020-03-12 2:21 ` Roman Mashak
2020-03-11 17:33 ` [PATCH net-next v2 6/6] selftests: mlxsw: RED: Test RED ECN taildrop offload Petr Machata
2020-03-15 4:04 ` [PATCH net-next v2 0/6] RED: Introduce an ECN tail-dropping mode David Miller
2020-03-16 10:54 ` Petr Machata
2020-03-16 21:55 ` David Miller
2020-03-17 12:43 ` Petr Machata
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=20200311150920.306de7c6@kicinski-fedora-PC1C0HJN \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=jhs@mojatatu.com \
--cc=jiri@mellanox.com \
--cc=mlxsw@mellanox.com \
--cc=mrv@mojatatu.com \
--cc=netdev@vger.kernel.org \
--cc=petrm@mellanox.com \
--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