From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v3 2/2] ethdev: add hierarchical scheduler API Date: Thu, 16 Mar 2017 18:35:15 +0100 Message-ID: <3726722.PXkB3N0h2d@xps13> References: <1488589820-206947-1-git-send-email-cristian.dumitrescu@intel.com> <1488589820-206947-3-git-send-email-cristian.dumitrescu@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, jerin.jacob@caviumnetworks.com, balasubramanian.manoharan@cavium.com, hemant.agrawal@nxp.com, shreyansh.jain@nxp.com To: Cristian Dumitrescu Return-path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 310831075 for ; Thu, 16 Mar 2017 18:35:17 +0100 (CET) Received: by mail-wm0-f49.google.com with SMTP id n11so118015506wma.1 for ; Thu, 16 Mar 2017 10:35:17 -0700 (PDT) In-Reply-To: <1488589820-206947-3-git-send-email-cristian.dumitrescu@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2017-03-04 01:10, Cristian Dumitrescu: > This patch introduces the generic ethdev API for the traffic manager > capability, which includes: hierarchical scheduling, traffic shaping, > congestion management, packet marking. > > Main features: > - Exposed as ethdev plugin capability (similar to rte_flow approach) > - Capability query API per port, per hierarchy level and per hierarchy node > - Scheduling algorithms: Strict Priority (SP), Weighed Fair Queuing (WFQ), > Weighted Round Robin (WRR) > - Traffic shaping: single/dual rate, private (per node) and shared (by multiple > nodes) shapers > - Congestion management for hierarchy leaf nodes: algorithms of tail drop, > head drop, WRED; private (per node) and shared (by multiple nodes) WRED > contexts > - Packet marking: IEEE 802.1q (VLAN DEI), IETF RFC 3168 (IPv4/IPv6 ECN for > TCP and SCTP), IETF RFC 2597 (IPv4 / IPv6 DSCP) Please could you split some parts of this API in separate patches? And it would be nice to add some text in the programmer's guide as part of the API patches. It will help the review. It could provide you the opportunity to explain the rationale in the commit messages of each part and save it in the git history. Last detail, please Cristian, try to be concise when writing such explanations ;) Thanks