netdev - Re: [patch net-next 00/17] mlxsw: Introduce support for Data Center Bridging

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20160406.172438.2294254065768146784.davem@davemloft.net>
Date:	Wed, 06 Apr 2016 17:24:38 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	jiri@...nulli.us
Cc:	netdev@...r.kernel.org, idosch@...lanox.com, eladr@...lanox.com,
	yotamg@...lanox.com, ogerlitz@...lanox.com,
	roopa@...ulusnetworks.com, gospo@...ulusnetworks.com
Subject: Re: [patch net-next 00/17] mlxsw: Introduce support for Data
 Center Bridging

From: Jiri Pirko <jiri@...nulli.us>
Date: Wed,  6 Apr 2016 17:09:59 +0200

> From: Jiri Pirko <jiri@...lanox.com>
> 
> Ido says:
> 
> This patchset introduces support for Quality of Service (QoS) as part of the
> IEEE Data Center Bridiging (DCB) standards.
> 
> Patches 1-9 do the required device initialization. Specifically, patches 1-6
> initialize the ports' headroom buffers, which are used at ingress to store
> incoming packets while they go through the switch's pipeline. Patches 7-9
> complete them by initializing the egress scheduling.
> 
> The pipeline mentioned above determines the packet's egress port(s) and
> traffic class. Ideally, once out of the pipeline the packet moves to the
> switch's shared buffer (to be introduced in Jiri's patchset, currently
> default values are used) and scheduled for transmission according to its
> traffic class. The egress scheduling is configured according to the 802.1Qaz
> standard, which is part of the DCB infrastructure supported by Linux. This
> is introduced in patches 10-12.
> 
> Even after going through the pipeline packets are not always eligible to
> enter the shared buffer. This is determined by the amount of available space
> and the quotas associated with the packet. However, if flow control is
> enabled and the packet is associated with the lossless flow, then it will
> stay in the headroom and won't be discarded. This is introduced in patches
> 13-17.
> 
> Please check individual commit messages for more info, as I tried to keep
> them pretty detailed.

Series applied, thanks guys.