From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Ricardo Leitner Subject: Re: [PATCH net-next v2 00/12] net: sched: propagate extack to cls offloads on destroy and only with skip_sw Date: Sun, 28 Jan 2018 20:39:02 -0200 Message-ID: <20180128223902.GI4000@localhost.localdomain> References: <20180124205424.6976-1-jakub.kicinski@netronome.com> <20180125151157.GA12972@localhost.localdomain> <20180125145717.6e57f508@cakuba.netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: davem@davemloft.net, jiri@resnulli.us, dsahern@gmail.com, daniel@iogearbox.net, john.fastabend@gmail.com, netdev@vger.kernel.org, oss-drivers@netronome.com, aring@mojatatu.com, Simon Horman , Eelco Chaudron To: Jakub Kicinski Return-path: Received: from mail-qt0-f196.google.com ([209.85.216.196]:46536 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751514AbeA1Xzb (ORCPT ); Sun, 28 Jan 2018 18:55:31 -0500 Received: by mail-qt0-f196.google.com with SMTP id o35so10606158qtj.13 for ; Sun, 28 Jan 2018 15:55:31 -0800 (PST) Content-Disposition: inline In-Reply-To: <20180125145717.6e57f508@cakuba.netronome.com> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Jan 25, 2018 at 02:57:17PM -0800, Jakub Kicinski wrote: > On Thu, 25 Jan 2018 13:11:57 -0200, Marcelo Ricardo Leitner wrote: > > On Wed, Jan 24, 2018 at 12:54:12PM -0800, Jakub Kicinski wrote: > > > Hi! > > > > > > This series some of Jiri's comments and the fact that today drivers > > > may produce extack even if there is no skip_sw flag (meaning the > > > driver failure is not really a problem), and warning messages will > > > only confuse the users. > > > > It's a fair point, but I think this is not the best solution. How will > > the user then know why it failed to install in hw? Will have to > > install a new rule, just with skip_sw, and hope that it fails with the > > same reason? > > > > Maybe it's better to let tc/ovs/etc only exhibit this information > > under a certain log/debug level. > > What you say does make sense in case of classifiers which are basically > HW offload vehicles. But for cls_bpf, which people are actually using > heavily as a software solution, I don't want any warning to be produced > just because someone happened to run the command on a Netronome > card :( Say someone swaps an old NIC for a NFP, and runs their old > cls_bpf scripts and suddenly there are warnings they don't care about > and have no way of silencing. (Sorry for the delay on replying, btw. I'm still traveling.) Makes sense. I agree that at least it shouldn't be displayed in a way that may lead the user to think it was a big/fatal error. > > I do think skip_sw will fail for the same reason, unless someone adds > extacks for IO or memory allocation problems or other transient things. I don't really follow this one. Fail you mean, fail to report the actual reason? If so, ok, but that's something easily fixable I think, especially because with skip_sw, if such an error happens, it's fatal for the operation so the error reporting is consistent. > > Do I understand correctly that OvS TC does not set skip_sw? We could Yes. > add a "verbose offload" flag to the API or filter the bad extacks at > the user space level. Although, again, my preference would be not to > filter at the user space level, because user space can't differentiate > between a probably-doesn't-matter-but-HW-offload-failed warning or legit > something-is-not-right-in-the-software-but-command-succeeded warning :S But userspace is the original requester. It should know what the rule is intended for and how to act upon it. For ovs, for example, it could just log a message and move on, while tc could report "hey, ok, but please note that the rule couldn't be offloaded". > So if there is a major use for non-forced offload failure warnings I > would lean towards a new flag. I'm thinking about this, still undecided. In the end maybe a counter somewhere could be enough and such reporting is not needed. Thinking.. Marcelo