From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id 8D92B914 for ; Mon, 6 Mar 2017 21:07:29 +0100 (CET) Received: by mail-wm0-f53.google.com with SMTP id t193so74293440wmt.1 for ; Mon, 06 Mar 2017 12:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=gcJ7XJtH4Wp1WQZkEpZ4OuR8Pe2ykOQP9BZvTyLKuNI=; b=Lnnx31RrYNwEfQpexBImEay2p1Sqd08VdS3ofQFn37Xb1JOWG92l/TwP/uoQ1MFXc1 BjnPG8ccLUo8NgbXWYNGqI42Xe3gTXMfXJui6pBA5DC3jibtU5i2vcZWYxJKP1R+XrnI H03/egh8bGQqIpPz++G0slZHBCcjdJ7FB4/XbNkUXr6kvQCim6MnWXh9FkUw4XDvn9pm HfMjmBqjkKYvFCBc7/tpSjfNPt52LdvvotJPGx/CdaoxNx56fIi3/CF0xyagwvHj0A8U aiXmH1VE851CmMpsYX+Q1MtBwWRLkBmHs9F8o/OklpoM+5nvMJsoTpPpLEU2WGmUwCu5 I0Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=gcJ7XJtH4Wp1WQZkEpZ4OuR8Pe2ykOQP9BZvTyLKuNI=; b=OlDeJO8sXfZSF8TyA0hjkmn+SxzFlbQ/GNFZZF/clvurAcKAj5p/BX0MDVCoJ8qhCX KkaXBYD3aWkvBsQTmgJHEsGYemQSeWE75FIRrCfowz6QqQFraZSbuEx4Eu2RFfVjew3Z ku5x6GEZhlSdiRBYL/6mlAYwiUJkrtkXTD63Cz1RcwuC6+nsXPAiuUcSoB8zudIHwiYf 6YWpX1ua98NW7DgCKULtjsCpOTAjo1LevJAbr+NXHiUPlNH/gGPI445k8mS/usxUAbEU lcphijp74F3DNw2Q0N5xJ09MZ8tmo2rgW3WNTjL38nDnDRDnli4e9EsePjBMqkQ6/MXF 7ung== X-Gm-Message-State: AMke39moGPeHIlKRyZvwrXi8rvVgP0/Hj1cosZlPOgydBSkNTYeYXq4nyrfXb4lhxIramzEf X-Received: by 10.28.59.193 with SMTP id i184mr15444974wma.97.1488830849311; Mon, 06 Mar 2017 12:07:29 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id z88sm28317397wrb.26.2017.03.06.12.07.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 12:07:28 -0800 (PST) From: Thomas Monjalon To: "Dumitrescu, Cristian" Cc: dev@dpdk.org, "jerin.jacob@caviumnetworks.com" , "balasubramanian.manoharan@cavium.com" , "hemant.agrawal@nxp.com" , "shreyansh.jain@nxp.com" , "Wiles, Keith" , "Richardson, Bruce" Date: Mon, 06 Mar 2017 21:07:26 +0100 Message-ID: <3752751.fl3uBnnZGo@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891265275A053@IRSMSX108.ger.corp.intel.com> References: <1488589820-206947-1-git-send-email-cristian.dumitrescu@intel.com> <6158991.OypYtkqGNY@xps13> <3EB4FA525960D640B5BDFFD6A3D891265275A053@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 2/2] ethdev: add hierarchical scheduler API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 20:07:29 -0000 2017-03-06 16:59, Dumitrescu, Cristian: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 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. > > > > We already have some API for QoS. Why integrating them in ethdev? > > ethdev is an interface for networking drivers. > > I think the QoS has nothing to do with drivers. > > If there are some operations to offload in drivers, please identify them > > and let's add the operations to ethdev. > > > > The reason to add to ethdev is because QoS traffic management/hierarchical scheduling is just another TX offload for Ethernet devices. This TX offload is present in NICs, NPUs and SoCs from Broadcom, Cavium, Intel, Mellanox, Netronome, NXP, others. > > The API we currently have in DPDK (librte_sched) is great, but it refers to an implementation for a fixed set of features for a BRAS-like hierarchy. The current abstraction layer proposal is intended to support pretty much any hierarchy and traffic management features such as hierarchical scheduling, traffic shaping, congestion management, marking under the same API. It targets pretty much any implementation, either HW, SW or hybrid; it does support the existing librte_sched library feature set, but it is not limited to it. OK I better understand now. You should add this level of explanation in your patch. However I am reluctant to add an API if there is no user. I think we should wait to have at least one existing driver implementing this API before integrating it. It was the approach of eventdev which has a dedicated next- tree.