From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [PATCH net-next] sched: cls: enable verbose logging Date: Tue, 15 May 2018 12:43:29 -0700 Message-ID: <20180515124329.61d70a0c@cakuba> References: <763cd60ed7addf605daf8b77c8639c5c08ada219.1526243501.git.marcelo.leitner@gmail.com> <20180514204725.GT4977@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Marcelo Ricardo Leitner , Linux Kernel Network Developers , David Ahern , Stephen Hemminger , Jiri Pirko , Alexander Aring , Jamal Hadi Salim To: Cong Wang Return-path: Received: from mx3.wp.pl ([212.77.101.9]:35112 "EHLO mx3.wp.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750810AbeEOTni (ORCPT ); Tue, 15 May 2018 15:43:38 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Mon, 14 May 2018 22:31:46 -0700, Cong Wang wrote: > On Mon, May 14, 2018 at 1:47 PM, Marcelo Ricardo Leitner wrote: > > On Mon, May 14, 2018 at 01:30:53PM -0700, Cong Wang wrote: > >> On Sun, May 13, 2018 at 1:44 PM, Marcelo Ricardo Leitner wrote: > >> > Currently, when the rule is not to be exclusively executed by the > >> > hardware, extack is not passed along and offloading failures don't > >> > get logged. The idea was that hardware failures are okay because the > >> > rule will get executed in software then and this way it doesn't confuse > >> > unware users. > >> > > >> > But this is not helpful in case one needs to understand why a certain > >> > rule failed to get offloaded. Considering it may have been a temporary > >> > failure, like resources exceeded or so, reproducing it later and knowing > >> > that it is triggering the same reason may be challenging. > >> > >> I fail to understand why you need a flag here, IOW, why not just pass > >> extack unconditionally? > > > > Because (as discussed in the RFC[1], should have linked it here) it > > could confuse users that are not aware of offloading and, in other > > cases, it can be just noise (like it would be right now for ebpf, > > which is mostly used in sw-path). > > > > 1.https://www.mail-archive.com/netdev@vger.kernel.org/msg223016.html > > My point is that a TC filter flag should be used for a filter attribute, > logging is apparently not a part of filter. At least, put it into HW offloading, > not in TC filter. > > I know DaveM hates module parameters, but a module parameter here > is more suitable than a TC filter flag. Do you mean we should add a global cls_flower parameter to enable verbose HW offload messages? I'm not sure where "HW offloading" is. I agree with you in principle, this could be made a "per application context" flag. Perhaps to be set on the socket. But our existing flags are per-request so it makes sense to do the same here IMHO.