[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171230102550.GB2127@nanopsycho>
Date: Sat, 30 Dec 2017 11:25:50 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Andrew Lunn <andrew@...n.ch>
Cc: Arkadi Sharshevsky <arkadis@...lanox.com>,
David Ahern <dsa@...ulusnetworks.com>,
Yuval Mintz <yuvalm@...lanox.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
mlxsw <mlxsw@...lanox.com>,
"vivien.didelot@...oirfairelinux.com"
<vivien.didelot@...oirfairelinux.com>,
"f.fainelli@...il.com" <f.fainelli@...il.com>,
"michael.chan@...adcom.com" <michael.chan@...adcom.com>,
"ganeshgr@...lsio.com" <ganeshgr@...lsio.com>,
Saeed Mahameed <saeedm@...lanox.com>,
Matan Barak <matanb@...lanox.com>,
Leon Romanovsky <leonro@...lanox.com>,
Ido Schimmel <idosch@...lanox.com>,
"jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
"ast@...nel.org" <ast@...nel.org>,
"daniel@...earbox.net" <daniel@...earbox.net>,
"simon.horman@...ronome.com" <simon.horman@...ronome.com>,
"pieter.jansenvanvuuren@...ronome.com"
<pieter.jansenvanvuuren@...ronome.com>,
"john.hurley@...ronome.com" <john.hurley@...ronome.com>,
"alexander.h.duyck@...el.com" <alexander.h.duyck@...el.com>,
"linville@...driver.com" <linville@...driver.com>,
"gospo@...adcom.com" <gospo@...adcom.com>,
"steven.lin1@...adcom.com" <steven.lin1@...adcom.com>,
Or Gerlitz <ogerlitz@...lanox.com>,
"roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>,
Shrijeet Mukherjee <shm@...ulusnetworks.com>
Subject: Re: [patch net-next v2 00/10] Add support for resource abstraction
Sat, Dec 30, 2017 at 11:18:50AM CET, andrew@...n.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.
Powered by blists - more mailing lists