From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arkadi Sharshevsky Subject: Re: mlxsw and rtnl lock Date: Wed, 30 Aug 2017 00:18:52 +0300 Message-ID: References: <20170826170418.GA22324@shredder> <2723f732-b337-a792-05ee-4a1461bf2aad@mellanox.com> <59774544-88d7-1f2a-82c6-28bb6c7ac747@gmail.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: David Ahern , Ido Schimmel Return-path: Received: from mail-eopbgr10080.outbound.protection.outlook.com ([40.107.1.80]:11680 "EHLO EUR02-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751263AbdH2VTB (ORCPT ); Tue, 29 Aug 2017 17:19:01 -0400 In-Reply-To: <59774544-88d7-1f2a-82c6-28bb6c7ac747@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: On 08/29/2017 11:04 PM, David Ahern wrote: > 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? > No, only the design RFC which describe the UAPI, devlink commands and the devlink/driver interactions. I wanted to receive some feedback before the coding.