netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Arkadi Sharshevsky <arkadis@mellanox.com>,
	David Ahern <dsa@cumulusnetworks.com>,
	Yuval Mintz <yuvalm@mellanox.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	mlxsw <mlxsw@mellanox.com>,
	"vivien.didelot@savoirfairelinux.com"
	<vivien.didelot@savoirfairelinux.com>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"michael.chan@broadcom.com" <michael.chan@broadcom.com>,
	"ganeshgr@chelsio.com" <ganeshgr@chelsio.com>,
	Saeed Mahameed <saeedm@mellanox.com>,
	Matan Barak <matanb@mellanox.com>,
	Leon Romanovsky <leonro@mellanox.com>,
	Ido Schimmel <idosch@mellanox.com>,
	"jakub.kicinski@netronome.com" <jakub.kicinski@netronome.com>,
	"ast@kernel.org" <ast@kernel.org>,
	"daniel@iogearbox.net" <daniel@iogearbox.net
Subject: Re: [patch net-next v2 00/10] Add support for resource abstraction
Date: Sat, 30 Dec 2017 11:25:50 +0100	[thread overview]
Message-ID: <20171230102550.GB2127@nanopsycho> (raw)
In-Reply-To: <20171230101850.GA25346@lunn.ch>

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.

  reply	other threads:[~2017-12-30 10:25 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-26 11:23 [patch net-next v2 00/10] Add support for resource abstraction Jiri Pirko
2017-12-26 11:23 ` [patch net-next v2 01/10] devlink: Add per devlink instance lock Jiri Pirko
2017-12-26 11:23 ` [patch net-next v2 02/10] devlink: Add support for resource abstraction Jiri Pirko
2017-12-26 11:23 ` [patch net-next v2 03/10] devlink: Add support for reload Jiri Pirko
2017-12-26 11:23 ` [patch net-next v2 04/10] devlink: Add relation between dpipe and resource Jiri Pirko
2017-12-26 11:23 ` [patch net-next v2 05/10] mlxsw: pci: Add support for performing bus reset Jiri Pirko
2017-12-26 11:23 ` [patch net-next v2 06/10] mlxsw: spectrum: Register KVD resources with devlink Jiri Pirko
2017-12-26 11:23 ` [patch net-next v2 07/10] mlxsw: spectrum_dpipe: Connect dpipe tables to resources Jiri Pirko
2017-12-26 11:23 ` [patch net-next v2 08/10] mlxsw: spectrum: Add support for getting kvdl occupancy Jiri Pirko
2017-12-26 11:23 ` [patch net-next v2 09/10] mlxsw: pci: Add support for getting resource through devlink Jiri Pirko
2017-12-26 11:23 ` [patch net-next v2 10/10] mlxsw: core: Add support for reload Jiri Pirko
2017-12-27  4:05 ` [patch net-next v2 00/10] Add support for resource abstraction David Ahern
2017-12-27  8:09   ` Jiri Pirko
2017-12-27  8:23     ` Andrew Lunn
2017-12-27  9:37       ` Jiri Pirko
2017-12-27 13:08         ` Andrew Lunn
2017-12-27 13:15           ` Jiri Pirko
2017-12-27 16:38             ` David Ahern
2017-12-27 19:31             ` Andrew Lunn
2017-12-27 20:16               ` David Ahern
2017-12-27  8:28     ` Yuval Mintz
2017-12-27 16:34     ` David Ahern
2017-12-27 19:43       ` Roopa Prabhu
2017-12-28  8:21         ` Yuval Mintz
2017-12-30 21:15           ` David Ahern
2017-12-31 10:52             ` Arkadi Sharshevsky
2017-12-31 15:46               ` David Ahern
2018-01-01 12:23                 ` Arkadi Sharshevsky
2017-12-27 20:15       ` Arkadi Sharshevsky
2017-12-28  8:25       ` Yuval Mintz
2017-12-28 16:09         ` David Ahern
2017-12-28 16:23           ` Jiri Pirko
2017-12-28 16:33             ` David Ahern
2017-12-28 16:43               ` Jiri Pirko
2017-12-29 17:09               ` Arkadi Sharshevsky
2017-12-30 10:18                 ` Andrew Lunn
2017-12-30 10:25                   ` Jiri Pirko [this message]
2017-12-30 17:26                     ` Andrew Lunn
2018-01-01 14:58 ` Arkadi Sharshevsky
2018-01-02 10:08   ` Jiri Pirko
2018-01-02 13:41     ` Andrew Lunn
2018-01-02 14:35       ` Jiri Pirko
2018-01-02 18:05   ` David Ahern
2018-01-03 18:05     ` Arkadi Sharshevsky
2018-01-03 18:14       ` David Ahern
2018-01-03 18:17         ` Jiri Pirko
2018-01-03 18:29           ` David Ahern
2018-01-03 18:36             ` Jiri Pirko
2018-01-04 16:58               ` David Ahern
2018-01-04 17:17                 ` David Miller
2018-01-25 15:24                 ` Jiri Pirko
2018-01-25 15:38                   ` David Ahern
2018-01-25 15:50                     ` Jiri Pirko
2018-01-04  0:07             ` Arkadi Sharshevsky
2018-01-04  2:28       ` David Ahern
2018-01-04  9:24         ` Arkadi Sharshevsky
2018-01-04 12:41           ` Andrew Lunn
2018-01-04 15:58           ` David Ahern
2018-01-04 16:13             ` Arkadi Sharshevsky
2018-01-04 16:44               ` David Ahern
2018-01-04 18:03               ` David Ahern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171230102550.GB2127@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=andrew@lunn.ch \
    --cc=arkadis@mellanox.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsa@cumulusnetworks.com \
    --cc=f.fainelli@gmail.com \
    --cc=ganeshgr@chelsio.com \
    --cc=idosch@mellanox.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=leonro@mellanox.com \
    --cc=matanb@mellanox.com \
    --cc=michael.chan@broadcom.com \
    --cc=mlxsw@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    --cc=vivien.didelot@savoirfairelinux.com \
    --cc=yuvalm@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).