From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [patch net-next v2 00/10] Add support for resource abstraction Date: Sat, 30 Dec 2017 11:25:50 +0100 Message-ID: <20171230102550.GB2127@nanopsycho> References: <20171226112359.5313-1-jiri@resnulli.us> <20171227080902.GA1997@nanopsycho> <22cc777b-e39e-29c0-22fe-aa7a99ef80df@cumulusnetworks.com> <20171228162314.GA1983@nanopsycho> <4bd0a9d4-350d-274c-6370-e3a98a1e4f93@cumulusnetworks.com> <77fbf905-77f1-96fb-921a-515ee71ece10@mellanox.com> <20171230101850.GA25346@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Arkadi Sharshevsky , David Ahern , Yuval Mintz , "netdev@vger.kernel.org" , "davem@davemloft.net" , mlxsw , "vivien.didelot@savoirfairelinux.com" , "f.fainelli@gmail.com" , "michael.chan@broadcom.com" , "ganeshgr@chelsio.com" , Saeed Mahameed , Matan Barak , Leon Romanovsky , Ido Schimmel , "jakub.kicinski@netronome.com" , "ast@kernel.org" , "daniel@iogearbox.net" Return-path: Received: from mail-wr0-f195.google.com ([209.85.128.195]:35801 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751010AbdL3KZw (ORCPT ); Sat, 30 Dec 2017 05:25:52 -0500 Received: by mail-wr0-f195.google.com with SMTP id l19so30963927wrc.2 for ; Sat, 30 Dec 2017 02:25:51 -0800 (PST) Content-Disposition: inline In-Reply-To: <20171230101850.GA25346@lunn.ch> Sender: netdev-owner@vger.kernel.org List-ID: Sat, Dec 30, 2017 at 11:18:50AM CET, andrew@lunn.ch wrote: >> 1. Both dpipe and devlink resource are abstraction models for >> hardware entities, and as a result they true to provide generic objects. >> Each driver/ASIC should register his own and it absolutely proprietary >> implementation. There is absolutely NO industry standard here, the only >> thing that resembles a standard is that dpipe looks a bit like P4 only >> because its proved to be useful for describing packet forwarding >> pipelines. The host4 table is just a hardware process in the mellanox >> spectrum ASIC pipeline and it should not be part of ABI, sorry I clearly >> don't understand how this even came up. > >Why should it not be part of the ABI? Are you saying it will change >from version to version? Are you trying to warning people not to write >scripts using it, because its meaning will change and what works now >will break in the next kernel version? In my opinion it should not change. Unless there is a bug (like the one DaveA found in mlxsw erif table). Existing tables and resources should be only added. It is the driver's maintainer responsibility to not to break user scripts.