[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200423125600.16956cc9@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Thu, 23 Apr 2020 12:56:00 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: Jesper Dangaard Brouer <brouer@...hat.com>, netdev@...r.kernel.org,
Ilias Apalodimas <ilias.apalodimas@...aro.org>,
Toke Høiland-Jørgensen
<toke@...hat.com>, ruxandra.radulescu@....com,
ioana.ciornei@....com, nipun.gupta@....com, shawnguo@...nel.org
Subject: Re: [PATCH net-next 2/2] dpaa2-eth: fix return codes used in
ndo_setup_tc
On Thu, 23 Apr 2020 12:33:56 -0700 Stephen Hemminger wrote:
> On Thu, 23 Apr 2020 17:38:04 +0200
> Jesper Dangaard Brouer <brouer@...hat.com> wrote:
>
> > On Thu, 23 Apr 2020 08:28:58 -0700
> > Stephen Hemminger <stephen@...workplumber.org> wrote:
> >
> > > On Thu, 23 Apr 2020 16:57:50 +0200
> > > Jesper Dangaard Brouer <brouer@...hat.com> wrote:
> > >
> > > > Drivers ndo_setup_tc call should return -EOPNOTSUPP, when it cannot
> > > > support the qdisc type. Other return values will result in failing the
> > > > qdisc setup. This lead to qdisc noop getting assigned, which will
> > > > drop all TX packets on the interface.
> > > >
> > > > Fixes: ab1e6de2bd49 ("dpaa2-eth: Add mqprio support")
> > > > Signed-off-by: Jesper Dangaard Brouer <brouer@...hat.com>
> > >
> > > Would it be possible to use extack as well?
> >
> > That is what patch 1/2 already does.
> >
> > > Putting errors in dmesg is unhelpful
> >
> > This patchset does not introduce any dmesg printk.
> >
>
> I was thinking that this
> if (num_tc > dpaa2_eth_tc_count(priv)) {
> netdev_err(net_dev, "Max %d traffic classes supported\n",
> dpaa2_eth_tc_count(priv));
> - return -EINVAL;
> + return -EOPNOTSUPP;
> }
>
> could be an extack message
That's a good question, actually. In this case Jesper was seeing a
failure when creating the default qdisc. The extack would go nowhere,
we'd have to print it to the logs, no? Which we should probably do,
anyway.
> but doing that would require a change
> to the ndo_setup_tc hook to allow driver to return its own error message
> as to why the setup failed.
Yeah :S The block offload command contains extack, but this driver
doesn't understand block offload, so it won't interpret it...
That brings me to an important point - doesn't the extack in patch 1
override any extack driver may have set?
I remember we discussed this when adding extacks to the TC core, but
I don't remember the conclusion now, ugh.
Powered by blists - more mailing lists