netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: David Ahern <dsa@cumulusnetworks.com>
Cc: Yuval Mintz <yuvalm@mellanox.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	Arkadi Sharshevsky <arkadis@mellanox.com>,
	mlxsw <mlxsw@mellanox.com>, "andrew@lunn.ch" <andrew@lunn.ch>,
	"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: Thu, 28 Dec 2017 17:23:14 +0100	[thread overview]
Message-ID: <20171228162314.GA1983@nanopsycho> (raw)
In-Reply-To: <22cc777b-e39e-29c0-22fe-aa7a99ef80df@cumulusnetworks.com>

Thu, Dec 28, 2017 at 05:09:09PM CET, dsa@cumulusnetworks.com wrote:
>On 12/28/17 2:25 AM, Yuval Mintz wrote:
>>>>> Again, I have no objections to kvd, linear, hash, etc terms as they do
>>>>> relate to Mellanox products. But kvd/linear, for example, does correlate
>>>>> to industry standard concepts in some way. My request is that the
>>>>> resource listing guide the user in some way, stating what these
>>>>> resources mean.
>>>>
>>>> So the showed relation to dpipe table would be enougn or you would still
>>>> like to see some description? I don't like the description concept here
>>>> as the relations to dpipe table should tell user exactly what he needs
>>>> to know.
>>>
>>> I believe it is useful to have a 1-line, short description that gives
>>> the user some memory jogger as to what the resource is used for. It does
>>> not have to be an exhaustive list, but the user should not have to do
>>> mental jumping jacks running a bunch of commands to understand the
>>> resources for vendor specific asics.
>> 
>> Perhaps we can simply have devlink utility output the dpipe
>> table[s] associated with the resource when showing the resource?
>> It would contain live information as well as prevent the need for
>> 'mental jumping jacks'.
>> 
>
>My primary contention for this static partitioning is that the proposal
>is not giving the user the information they need to make decisions.
>
>As I mentioned earlier, the resource show command gives this:
>$ devlink resource show pci/0000:03:00.0
>pci/0000:03:00.0:
>  name kvd size 245760 size_valid true
>  resources:
>    name linear size 98304 occ 0
>    name hash_double size 60416
>    name hash_single size 87040
>
>the paths /kvd/linear, /kvd/hash_single and /kvd/hash_double are
>essentially random names (nothing related to industry standard names)

Of course. There is no industry standard for internal ASIC
implementations. This is the same as for dpipe. There is no industry
standard for ASIC pipeline. dpipe visualizes it. This resource patch
visualizes the internal ASIC resources and their mapping to the
individual dpipe tables.


>and the listed sizes are random numbers (no units)[1]. There is nothing
>there to tell a user what they can adjust or why they would want to make
>an adjustment.
>
>
>Looking at 'dpipe table show':
>
>$ devlink dpipe table show pci/0000:03:00.0
>pci/0000:03:00.0:
>  name mlxsw_erif size 1000 counters_enabled false
>  match:
>    type field_exact header mlxsw_meta field erif_port mapping ifindex
>  action:
>    type field_modify header mlxsw_meta field l3_forward
>    type field_modify header mlxsw_meta field l3_drop
>
>  resource_path /kvd/hash_single name mlxsw_host4 size 62
>counters_enabled false
>  match:
>    type field_exact header mlxsw_meta field erif_port mapping ifindex
>    type field_exact header ipv4 field destination ip
>  action:
>    type field_modify header ethernet field destination mac
>
>  resource_path /kvd/hash_double name mlxsw_host6 size 0
>counters_enabled false
>  match:
>    type field_exact header mlxsw_meta field erif_port mapping ifindex
>    type field_exact header ipv6 field destination ip
>  action:
>    type field_modify header ethernet field destination mac
>
>  resource_path /kvd/linear name mlxsw_adj size 0 counters_enabled false
>  match:
>    type field_exact header mlxsw_meta field adj_index
>    type field_exact header mlxsw_meta field adj_size
>    type field_exact header mlxsw_meta field adj_hash_index
>  action:
>    type field_modify header ethernet field destination mac
>    type field_modify header mlxsw_meta field erif_port mapping ifindex
>
>
>So there are 4 tables exported to userspace:
>
>1. mlxsw_erif table which is not in any of the kvd regions (no resource
>path is given) and it has a size of 1000. Does mlxsw_erif mean a rif as
>in Router Interfaces? So the switch supports up to 1000 router interfaces.
>
>2. mlxsw_host4 in /kvd/hash_single with a size of 62. Based on the

Size tells you the actual size. It cannot give you max size. The reason
is simple. The resources are shared among multiple tables. That is
exactly what this resource patch makes visible.


>fields mlxsw_host4 means IPv4 host entries (neighbor entries). Why is
>the size set at 62? Seems really low.
>
>3. mlxsw_host6 in /kvd/hash_double with a size of 0. Based on the fields
>mlxsw_host6 means IPv6 host entries (neighbor entries). The size of 0 is
>concerning. I guess the switch is not configured to do IPv6?
>
>4. mlxsw_adj in /kvd/linear with a size of 0. Based on the fields I am
>going to guess it is an fdb entry????

  reply	other threads:[~2017-12-28 16:23 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 [this message]
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
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=20171228162314.GA1983@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).