From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net-next 0/6] net: sched: sch: introduce extack support Date: Wed, 06 Dec 2017 17:36:14 -0500 (EST) Message-ID: <20171206.173614.687075860589810652.davem@davemloft.net> References: <20171206160845.6646-1-aring@mojatatu.com> <20171206.154009.1362727654214640336.davem@davemloft.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: jhs@mojatatu.com, xiyou.wangcong@gmail.com, jiri@resnulli.us, netdev@vger.kernel.org, kernel@mojatatu.com, dsahern@gmail.com To: aring@mojatatu.com Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:56278 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751604AbdLFWgV (ORCPT ); Wed, 6 Dec 2017 17:36:21 -0500 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: From: Alexander Aring Date: Wed, 6 Dec 2017 17:34:08 -0500 > Hi, > > On Wed, Dec 6, 2017 at 3:40 PM, David Miller wrote: >> From: Alexander Aring >> Date: Wed, 6 Dec 2017 11:08:39 -0500 >> >>> this patch series basically add support for extack in common qdisc handling. >>> Additional it adds extack pointer to common qdisc callback handling this >>> offers per qdisc implementation to setting the extack message for each >>> failure over netlink. >>> >>> The extack message will be set deeper in qdisc functions but going not >>> deeper as net core api. For qdisc module callback handling, the extack >>> will not be set. This will be part of per qdisc extack handling. >>> >>> I also want to prepare patches to handle extack per qdisc module... >>> so there will come a lot of more patches, just cut them down to make >>> it reviewable. >>> >>> There are some above 80-chars width warnings, which I ignore because >>> it looks more ugly otherwise. >>> >>> This patch-series based on patches by David Ahren which gave me some >>> hints how to deal with extack support. >>> >>> Cc: David Ahern >> >> Only add the plumbing when you have actual extack messages you are >> adding as an example use case. >> > > I did not understand. I have a lot of patches which make use of these > changes. Do you want me to submit me these in one shot (patch-series)? > I was hoping to making it in smaller patch-series for easier review. Submit one plumbing patch alongside the changes that actually add messages in those code paths. This patch series did plumbing in many spots, one patch at a time, but added no users except in the initial path. That's what I don't like.