All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Michel Machado <michel@digirati.com.br>,
	Nishanth Devarajan <ndev2021@gmail.com>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	Jiri Pirko <jiri@resnulli.us>, David Miller <davem@davemloft.net>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	Cody Doucette <doucette@bu.edu>
Subject: Re: [PATCH v3 net-next] net/sched: add skbprio scheduler
Date: Wed, 11 Jul 2018 16:33:36 -0300	[thread overview]
Message-ID: <20180711193336.GF8880@localhost.localdomain> (raw)
In-Reply-To: <CAM_iQpW9pqSMZfJsfntZtva8wrfsw8UpQAg0ryumu5pPbgJ2UQ@mail.gmail.com>

On Tue, Jul 10, 2018 at 07:25:53PM -0700, Cong Wang wrote:
> On Mon, Jul 9, 2018 at 2:40 PM Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> >
> > On Mon, Jul 09, 2018 at 05:03:31PM -0400, Michel Machado wrote:
> > >    Changing TC_PRIO_MAX from 15 to 63 risks breaking backward compatibility
> > > with applications.
> >
> > If done, it needs to be done carefully, indeed. I don't know if it's
> > doable, neither I know how hard is your requirement for 64 different
> > priorities.
> 
> struct tc_prio_qopt {
>         int     bands;                  /* Number of bands */
>         __u8    priomap[TC_PRIO_MAX+1]; /* Map: logical priority -> PRIO band */
> };
> 
> How would you do it carefully?

quick shot, multiplex v1 and v2 formats based on bands and sizeof():

#define TCQ_PRIO_BANDS_V1	16
#define TCQ_PRIO_BANDS_V2	64
#define TC_PRIO_MAX_V2		64

struct tc_prio_qopt_v2 {
        int     bands;                  /* Number of bands */
        __u8    priomap[TC_PRIO_MAX_V2+1]; /* Map: logical priority -> PRIO band */
};

static int prio_tune(struct Qdisc *sch, struct nlattr *opt,
                     struct netlink_ext_ack *extack)
{
        struct prio_sched_data *q = qdisc_priv(sch);
        struct Qdisc *queues[TCQ_PRIO_BANDS_V2];
        int oldbands = q->bands, i;
        struct tc_prio_qopt_v2 *qopt;

        if (nla_len(opt) < sizeof(int))
                return -EINVAL;
        qopt = nla_data(opt);

	if (qopt->bands <= TCQ_PRIO_BANDS_V1 &&
            nla_len(opt) < sizeof(struct tc_prio_qopt))
                return -EINVAL;

	if (qopt->bands <= TCQ_PRIO_BANDS_V2 &&
            nla_len(opt) < sizeof(*qopt))
                return -EINVAL;

	/* By here, if it has up to 3 bands, we can assume it is using the _v1
	 * layout, while if it has up to TCQ_PRIO_BANDS_V2 it is using the _v2
	 * format.
	 */

        if (qopt->bands > TCQ_PRIO_BANDS_V2 || qopt->bands < 2)
                return -EINVAL;
...

With something like this I think it can keep compatibility with old
software while also allowing the new usage.

> Also, it is not only used by prio but also pfifo_fast.

Yes. More is needed, indeed. prio2band would also need to be expanded,
etc. Yet, I still don't see any blocker.

  reply	other threads:[~2018-07-11 19:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-07 10:13 [PATCH v3 net-next] net/sched: add skbprio scheduler Nishanth Devarajan
2018-07-09 15:44 ` Marcelo Ricardo Leitner
2018-07-09 18:18   ` Michel Machado
2018-07-09 19:53     ` Marcelo Ricardo Leitner
2018-07-09 21:03       ` Michel Machado
2018-07-09 21:40         ` Marcelo Ricardo Leitner
2018-07-10 14:03           ` Michel Machado
2018-07-10 14:33             ` Marcelo Ricardo Leitner
2018-07-11  2:25           ` Cong Wang
2018-07-11 19:33             ` Marcelo Ricardo Leitner [this message]
2018-07-13  6:05               ` Cong Wang
2018-07-13 13:04                 ` Marcelo Ricardo Leitner
2018-07-13 18:26                   ` Cong Wang
2018-07-14  4:39                     ` Marcelo Ricardo Leitner
2018-07-17  6:41                       ` Cong Wang
2018-07-11  2:32       ` Cong Wang
2018-07-11 18:37         ` Marcelo Ricardo Leitner
2018-07-13  5:07           ` Cong Wang
2018-07-13 13:00             ` Marcelo Ricardo Leitner
2018-07-13 18:17               ` Cong Wang
2018-07-14  4:51                 ` Marcelo Ricardo Leitner
2018-07-17  5:36                   ` Cong Wang
2018-07-11  2:38     ` Cong Wang
2018-07-11  2:57 ` Cong Wang
2018-07-11 15:24   ` Michel Machado
2018-07-19 18:39     ` Cong Wang

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=20180711193336.GF8880@localhost.localdomain \
    --to=marcelo.leitner@gmail.com \
    --cc=davem@davemloft.net \
    --cc=doucette@bu.edu \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=michel@digirati.com.br \
    --cc=ndev2021@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.