From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Ricardo Leitner Subject: Re: [PATCH net-next] sched: cls: enable verbose logging Date: Mon, 14 May 2018 17:47:25 -0300 Message-ID: <20180514204725.GT4977@localhost.localdomain> References: <763cd60ed7addf605daf8b77c8639c5c08ada219.1526243501.git.marcelo.leitner@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linux Kernel Network Developers , Jakub Kicinski , David Ahern , Stephen Hemminger , Jiri Pirko , Alexander Aring , Jamal Hadi Salim To: Cong Wang Return-path: Received: from mail-qt0-f196.google.com ([209.85.216.196]:38374 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752041AbeENUra (ORCPT ); Mon, 14 May 2018 16:47:30 -0400 Received: by mail-qt0-f196.google.com with SMTP id m9-v6so18032880qtb.5 for ; Mon, 14 May 2018 13:47:29 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: 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