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.
