[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171230101850.GA25346@lunn.ch>
Date: Sat, 30 Dec 2017 11:18:50 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Arkadi Sharshevsky <arkadis@...lanox.com>
Cc: David Ahern <dsa@...ulusnetworks.com>,
Jiri Pirko <jiri@...nulli.us>,
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
> 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?
Andrew
Powered by blists - more mailing lists