From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: mlxsw and rtnl lock Date: Tue, 29 Aug 2017 14:04:59 -0600 Message-ID: <59774544-88d7-1f2a-82c6-28bb6c7ac747@gmail.com> References: <20170826170418.GA22324@shredder> <2723f732-b337-a792-05ee-4a1461bf2aad@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Jiri Pirko , "netdev@vger.kernel.org" , mlxsw@mellanox.com To: Arkadi Sharshevsky , Ido Schimmel Return-path: Received: from mail-pg0-f66.google.com ([74.125.83.66]:37679 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751186AbdH2UFC (ORCPT ); Tue, 29 Aug 2017 16:05:02 -0400 Received: by mail-pg0-f66.google.com with SMTP id t193so3455416pgc.4 for ; Tue, 29 Aug 2017 13:05:02 -0700 (PDT) In-Reply-To: <2723f732-b337-a792-05ee-4a1461bf2aad@mellanox.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 8/29/17 12:10 AM, Arkadi Sharshevsky wrote: > > > On 08/28/2017 09:00 PM, David Ahern wrote: >> On 8/26/17 11:04 AM, Ido Schimmel wrote: >>> Regarding the silent abort, that's intentional. You can look at the same >>> code in v4.9 - when the chain was still blocking - and you'll see that >>> we didn't propagate the error even then. This was discussed in the past >>> and the conclusion was that user doesn't expect to operation to fail. If >>> hardware resources are exceeded, we let the kernel take care of the >>> forwarding instead. >>> >> >> In addition to Roopa's comments... The silent abort is not a good user >> experience. Right now it's add a network address or route, cross fingers >> and hope it does not overflow some limit (nexthop, ecmp, neighbor, >> prefix, etc) that triggers the offload abort. >> >> The mlxsw driver queries for some limits (e.g., max rifs) but I don't >> see any query related to current usage, and there is no API to pass any >> of that data to user space so user space has no programmatic way to >> handle this. I realize you are aware of this limitation. The point is to >> emphasize the need to resolve this. >> > > We actually thought about providing he user some tools to understand > the ASIC's limitations by introducing the 'resource' object to devlink. > > By linking dpipe tables to resources the user can understand which > hardware processes share a common resource, furthermore this resources > usage could be observed. By this more visibility can be obtained. > > Its not a remedy for the silent abort, but, maybe a notification > can be sent from devlink in case of abort that some resources is > full. > > This proposition was sent as RFC several weeks ago. > Do you have patches (kernel and devlink) for the proposal?