[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180302144539.GE3887@localhost.localdomain>
Date: Fri, 2 Mar 2018 11:45:39 -0300
From: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To: Alexander Aring <aring@...atatu.com>
Cc: Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kubakici@...pl>,
netdev@...r.kernel.org, nogahf@...lanox.com, yuvalm@...lanox.com,
David Miller <davem@...emloft.net>, idosch@...lanox.com,
mlxsw@...lanox.com, Jamal Hadi Salim <jhs@...atatu.com>,
Cong Wang <xiyou.wangcong@...il.com>, kernel@...atatu.com
Subject: Re: [patch net-next 09/10] net: sch: prio: Add offload ability for
grafting a child
On Fri, Mar 02, 2018 at 09:21:56AM -0500, Alexander Aring wrote:
> Hi,
>
> On Fri, Mar 2, 2018 at 3:37 AM, Jiri Pirko <jiri@...nulli.us> wrote:
> > Fri, Mar 02, 2018 at 04:48:40AM CET, kubakici@...pl wrote:
> >>On Thu, 1 Mar 2018 22:38:50 -0500, Alexander Aring wrote:
> >>> I guess to make extack working, you need to return an errno if failed.
> >>
> >>AFAIK extack is printed as a warning if operation did not fail.
> >
> > Yes, I checked this and it is printed as warning.
>
> ouch, so far I know extack it allows only one messages delivered back
> to the user space.
>
> If we introduce a warning in the successful path here, it could be
> that in the callpath (after "successful" part of this callback), that
> somebody else want to add a warning and overwrites actually your
> warning (even, he is not aware that this warning was set - okay I
> suppose you can do another check on NULL and set a warning, that
> somebody overwrites a warning :-D).
>
> If extack messages get's append and is some kind of for_each_nested
> string in netlink -> we have no problem, but I guess this not how it's
> working. :-/
IOW I guess what we are looking for here is a way to use extack to
track more than an error/warning message, but to be a bit more
complete error reporting tool.
The case here is pretty much like the case with tc flower offloading,
to issue a message when it couldn't offload while it wasn't fatal for
the rule (in case SKIP_SW wasn't specified). The reason for why the
offloading couldn't happen could have been a temporary one and such
log of a warning is important for troubleshooting.
Marcelo
Powered by blists - more mailing lists