From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx4.wp.pl ([212.77.101.11]:56401 "EHLO mx4.wp.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751753AbeCPWF0 (ORCPT ); Fri, 16 Mar 2018 18:05:26 -0400 Date: Fri, 16 Mar 2018 15:05:18 -0700 From: Jakub Kicinski To: Marcelo Ricardo Leitner Cc: netdev@vger.kernel.org, Alexander Aring , Jiri Pirko , David Ahern Subject: Re: [PATCH RFC 0/2] Add support for warnings to extack Message-ID: <20180316150518.0641d03a@cakuba.netronome.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: CC: David Ahern On Fri, 16 Mar 2018 16:23:08 -0300, Marcelo Ricardo Leitner wrote: > Currently we have the limitation that warnings cannot be reported though > extack. For example, when tc flower failed to get offloaded but got > installed on software datapath. The hardware failure is not fatal and > thus extack is not even shared with the driver, so the error is simply > omitted from any logging. > > The idea here is to allow such kind of warnings to get through and be > available for the sysadmin or the tool managing such commands (like Open > vSwitch), so that if this happens, we will have such log message in a > file later. > > The first patch extends extack to support more than one message and with > different log level (currently only error and warning). The second > shares extack with the drivers regardless of skip_sw. > > The iproute patch also follows. > > This kernel change is backward compatible with older iproute because > iproute will only process the last message, which should be the error > one in case of failure, or a warning if it suceeded. > > The iproute change is compatible with older kernels because it will find > only one message to be processed and will handle it properly. > > With this patches, this is now possible: > # tc qdisc add dev p7p1 ingress > # tc filter add dev p7p1 parent ffff: protocol ip prio 1 flower \ > src_mac ec:13:db:00:00:00 dst_mac ec:14:c2:00:00:00 \ > src_ip 56.0.0.0 dst_ip 55.0.0.0 action drop > Warning: TC offload is disabled on net device. > # echo $? > 0 IMHO this set does more and less than is required to solve the problem. The way I understand it is we don't want HW offload errors/warnings to be printed to unsuspecting users who didn't specify any skip_* flags. What carries the message and whether it's explicitly marked as warning or error does not change the fact that user of the SW fwd path may not want to not be bothered by offload warnings. There maybe well be value in ability to report multiple messages. But for opt-in warning messages I would be leaning towards: diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h index e828d31be5dae0ae8c69016dfde50379296484aa..7cec393bb47974b48a6d510b8aa84534a7a98594 100644 --- a/include/net/pkt_cls.h +++ b/include/net/pkt_cls.h @@ -705,8 +705,7 @@ tc_cls_common_offload_init(struct tc_cls_common_offload *cls_common, cls_common->chain_index = tp->chain->index; cls_common->protocol = tp->protocol; cls_common->prio = tp->prio; - if (tc_skip_sw(flags)) + if (tc_skip_sw(flags) || flags & TCA_CLS_FLAGS_OFFLOAD_VERBOSE) cls_common->extack = extack; } enum tc_fl_command { That is admittedly quite conservative. Esp. in case of flower, cls_bpf is used in SW far more than HW, not to mention qdisc offload (although flag would be different there)!