On Mon, May 14, 2018 at 1:47 PM, Marcelo Ricardo Leitner <marcelo.leit...@gmail.com> 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 >> <marcelo.leit...@gmail.com> 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.
