From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ido Schimmel Subject: Re: [PATCH net-next 0/6] net: Allow FIB notifiers to fail add and replace Date: Thu, 29 Mar 2018 11:29:34 +0300 Message-ID: <20180329082934.GG22733@splinter> References: <20180328012200.15175-1-dsa@cumulusnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org, davem@davemloft.net, roopa@cumulusnetworks.com, shm@cumulusnetworks.com, jiri@mellanox.com, idosch@mellanox.com, jakub.kicinski@netronome.com, andy.roulin@gmail.com To: David Ahern Return-path: Received: from out5-smtp.messagingengine.com ([66.111.4.29]:42425 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751161AbeC2I3g (ORCPT ); Thu, 29 Mar 2018 04:29:36 -0400 Content-Disposition: inline In-Reply-To: <20180328012200.15175-1-dsa@cumulusnetworks.com> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Mar 27, 2018 at 06:21:54PM -0700, David Ahern wrote: > I wanted to revisit how resource overload is handled for hardware offload > of FIB entries and rules. At the moment, the in-kernel fib notifier can > tell a driver about a route or rule add, replace, and delete, but the > notifier can not affect the action. Specifically, in the case of mlxsw > if a route or rule add is going to overflow the ASIC resources the only > recourse is to abort hardware offload. Aborting offload is akin to taking > down the switch as the path from data plane to the control plane simply > can not support the traffic bandwidth of the front panel ports. Further, > the current state of FIB notifiers is inconsistent with other resources > where a driver can affect a user request - e.g., enslavement of a port > into a bridge or a VRF. > > As a result of the work done over the past 3+ years, I believe we are > at a point where we can bring consistency to the stack and offloads, > and reliably allow the FIB notifiers to fail a request, pushing an error > along with a suitable error message back to the user. Rather than > aborting offload when the switch is out of resources, userspace is simply > prevented from adding more routes and has a clear indication of why. Nice work, David. Ran various tests and didn't see any regressions. I know you already know this, but for the record, we plan to add accounting to KVD hash resources which will eventually allow us to return errors when resources are exceeded.