lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180524171321.GA1307@splinter>
Date:   Thu, 24 May 2018 20:13:21 +0300
From:   Ido Schimmel <idosch@...sch.org>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Huy Nguyen <huyn@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Jiri Pirko <jiri@...nulli.us>,
        Or Gerlitz <gerlitz.or@...il.com>,
        Parav Pandit <parav@...lanox.com>,
        Ido Schimmel <idosch@...lanox.com>
Subject: Re: [net-next 1/6] net/dcb: Add dcbnl buffer attribute

Hi Jakub,

On Wed, May 23, 2018 at 02:23:14AM -0700, Jakub Kicinski wrote:
> Are you referring to XOFF/XON thresholds?  I don't think the "threshold
> type" in devlink API implies we are setting XON/XOFF thresholds
> directly :S  If PFC is enabled we may be setting them indirectly,
> obviously.
> 
> My understanding is that for static threshold type the size parameter
> specifies the max amount of memory given pool can consume.

Correct.

> Yes, we must have a different definitions of "shared buffer" :)  That
> link, however, didn't clarify much for me...  In mlx5 you seem to have a
> buffer which is shared between priorities, even if it's not what would
> be referred to as shared buffer in switch context.

The following link is my attempt at explaining the above concepts:
https://github.com/Mellanox/mlxsw/wiki/Quality-of-Service

Please let me know if something is not clear.

Basically, we use devlink-sb and dcbl to configure two different
buffers:

* devlink-sb is used to configure the switch's shared buffer which is
shared between all the ports and thus can't take a netdev as an handle

* dcbnl is used to configure per-port buffers (also called headroom
buffers) where received packets are stored while going through the
switch's pipeline before being admitted to the shared buffer and
awaiting transmission

Note that in Huy's case the buffers are of the second type (per-port)
and thus using dcbnl instead of devlink-sb makes sense.

> DCBNL seems to carry standard-based information, which this is not.
> mlxsw supports DCBNL, will it also support this buffer configuration
> mechanism?

I believe so, it's just a matter of doing the work. The hardware
supports this and the interface is identical to the NIC (same
registers).

> > >    How does one query the total size of the buffer to be carved?  
> > [HQN] This is not necessary. If the total size is too big, error will
> > be return via DCB netlink interface.
> 
> Right, I'm not saying it's a bug :)  It's just nice when user can be
> told the total size without having to probe for it :)

+1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ