[{"id":1761986,"web_url":"http://patchwork.ozlabs.org/comment/1761986/","msgid":"<1519366e-5418-4dda-db00-5bf50a1c67c4@intel.com>","list_archive_url":null,"date":"2017-09-01T16:12:17","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":72279,"url":"http://patchwork.ozlabs.org/api/people/72279/","name":"Jesus Sanchez-Palencia","email":"jesus.sanchez-palencia@intel.com"},"content":"Hi Richard,\n\n\nOn 09/01/2017 06:03 AM, Richard Cochran wrote:\n> \n> I happy to see this posted. At first glance, it seems like a step in\n> the right direction.\n> \n> On Thu, Aug 31, 2017 at 06:26:20PM -0700, Vinicius Costa Gomes wrote:\n>> * Time-aware shaper (802.1Qbv):\n> ...\n>> S 0x01 300\n>> S 0x03 500\n>>\n>> This means that there are two intervals, the first will have the gate\n>> for traffic class 0 open for 300 nanoseconds, the second will have\n>> both traffic classes open for 500 nanoseconds.\n> \n> The i210 doesn't support this in HW, or does it?\n\n\nNo, it does not. i210 only provides support for a per-packet feature called\nLaunchTime that can be used control both the fetch and the transmission time of\npackets.\n\n\n> \n>> * Frame Preemption (802.1Qbu):\n>>\n>> To control even further the latency, it may prove useful to signal which\n>> traffic classes are marked as preemptable. For that, 'taprio' provides the\n>> preemption command so you set each traffic class as preemptable or not:\n>>\n>> $ tc qdisc (...) \\\n>> preemption 0 1 1 1\n> \n> Neither can the i210 preempt frames, or what am I missing?\n\nNo, it does not.\n\nBut when we started working on the shapers we decided to look ahead and try to\ncome up with interfaces that could cover beyond 802.1Qav. These are just some\nideas we've been prototyping here together with the 'cbs' qdisc.\n\n\n> \n> The timing of this RFC is good, as I am just finishing up an RFC that\n> implements time-based transmit using the i210. I'll try and get that\n> out ASAP.\n\n\nIs it correct to assume you are referring to an interface for Launchtime here?\n\n\nThanks,\nJesus","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","Received":["from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xkXM91ncJz9sPm\n\tfor ;\n\tSat, 2 Sep 2017 07:24:53 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 7B4A088FE0;\n\tFri, 1 Sep 2017 21:24:51 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id kRrz7bIpsoBf; Fri, 1 Sep 2017 21:24:50 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 13F5A88FE9;\n\tFri, 1 Sep 2017 21:24:50 +0000 (UTC)","from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id E44F71C037C\n\tfor ;\n\tFri, 1 Sep 2017 16:18:37 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id D9DE82F37C\n\tfor ;\n\tFri, 1 Sep 2017 16:18:37 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id ozswNO8CYp+S for ;\n\tFri, 1 Sep 2017 16:18:37 +0000 (UTC)","from mga05.intel.com (mga05.intel.com [192.55.52.43])\n\tby silver.osuosl.org (Postfix) with ESMTPS id 2FC102A293\n\tfor ;\n\tFri, 1 Sep 2017 16:18:37 +0000 (UTC)","from orsmga003.jf.intel.com ([10.7.209.27])\n\tby fmsmga105.fm.intel.com with ESMTP; 01 Sep 2017 09:18:36 -0700","from darjeeling.jf.intel.com (HELO [10.7.201.15]) ([10.7.201.15])\n\tby orsmga003.jf.intel.com with ESMTP; 01 Sep 2017 09:18:36 -0700"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos; i=\"5.41,459,1498546800\"; d=\"scan'208\";\n\ta=\"1010067222\"","To":"Richard Cochran ,\n\tVinicius Costa Gomes ","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170901130311.v5nyx6e6gfats5dg@localhost>","From":"Jesus Sanchez-Palencia ","Message-ID":"<1519366e-5418-4dda-db00-5bf50a1c67c4@intel.com>","Date":"Fri, 1 Sep 2017 09:12:17 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170901130311.v5nyx6e6gfats5dg@localhost>","Content-Language":"en-US","X-Mailman-Approved-At":"Fri, 01 Sep 2017 21:24:44 +0000","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, \n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1763012,"web_url":"http://patchwork.ozlabs.org/comment/1763012/","msgid":"<20170905072058.giqnqfhcooqzc46w@localhost>","list_archive_url":null,"date":"2017-09-05T07:20:58","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":4009,"url":"http://patchwork.ozlabs.org/api/people/4009/","name":"Richard Cochran","email":"richardcochran@gmail.com"},"content":"On Fri, Sep 01, 2017 at 09:12:17AM -0700, Jesus Sanchez-Palencia wrote:\n> On 09/01/2017 06:03 AM, Richard Cochran wrote:\n> > The timing of this RFC is good, as I am just finishing up an RFC that\n> > implements time-based transmit using the i210. I'll try and get that\n> > out ASAP.\n\nI have an RFC series ready for net-next, but the the merge window just\nstarted. I'll post it when the window closes again...\n\nThanks,\nRichard","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"efW8ygR7\"; dkim-atps=neutral"],"Received":["from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmdRq3h7Vz9sPk\n\tfor ;\n\tTue, 5 Sep 2017 17:21:09 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 8D3B285FF1;\n\tTue, 5 Sep 2017 07:21:07 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id LZ473FtpONYa; Tue, 5 Sep 2017 07:21:06 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 6AFF585FBA;\n\tTue, 5 Sep 2017 07:21:06 +0000 (UTC)","from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\tby ash.osuosl.org (Postfix) with ESMTP id 05A051C0F86\n\tfor ;\n\tTue, 5 Sep 2017 07:21:05 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id F1D7986EDA\n\tfor ;\n\tTue, 5 Sep 2017 07:21:04 +0000 (UTC)","from hemlock.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id CcF+E6tWk9fw for ;\n\tTue, 5 Sep 2017 07:21:04 +0000 (UTC)","from mail-wr0-f194.google.com (mail-wr0-f194.google.com\n\t[209.85.128.194])\n\tby hemlock.osuosl.org (Postfix) with ESMTPS id 2CA7D86ECE\n\tfor ;\n\tTue, 5 Sep 2017 07:21:04 +0000 (UTC)","by mail-wr0-f194.google.com with SMTP id y15so1246340wrc.4\n\tfor ;\n\tTue, 05 Sep 2017 00:21:04 -0700 (PDT)","from localhost (213-225-35-115.nat.highway.a1.net.\n\t[213.225.35.115])\n\tby smtp.gmail.com with ESMTPSA id 95sm89103wrm.33.2017.09.05.00.21.00\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tTue, 05 Sep 2017 00:21:01 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=xZhSehtMCZvj6ex6v8XClczDwfpo8E0ZZvK331qdf64=;\n\tb=efW8ygR74qCPn/f/ouZN73PWsYTuCv6/uizCNic/MaVueD2J1MBK01gZTnE/XsQqhY\n\t3jPx93/aHFSOHESMWwHPppRbXH7lN7vRbWuEqIdSA4e9H4SzckZ6k4UqHnlU7NoQd3FL\n\tzoM/RCZ7X8nfHOGsspXx2UdLXFifob0tp0u6ghvQAanYUUQacgXRrBnOjPltu7KyEBL9\n\tIfhdiBSZPQ4JuoFYBil24aNmF+00+Gtvr+Y6BuxBcfSCre2CWW6Pzjuzb6Xqynu7SoS5\n\tWL3x1Fry3Rvh5yzZAhY677xpyA1xJS8vAw8dKIRKzcMjFInltdqmmprjU7CCOfqeyO9+\n\t1aqw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=xZhSehtMCZvj6ex6v8XClczDwfpo8E0ZZvK331qdf64=;\n\tb=fwMAFnirNu3t3+rvg7X+ghhn/pcV7xVgLJI6s7rwx+1HMnz/eucHv6GSl8fjEwm8Xz\n\tTnoTTbh8rRMXysc8vLaiZg+24X9sphyvMy9Terffsa7UDL/3HIi9sybiVU95MWZ4TrSA\n\t3GGWJvHy3j4ORqf4mTjENVKFv8+3+GCxRh1F0VPyU7ZEUxNVNEz8jBVASf2veavDIoix\n\tRq38/XBNQYR3FiCsui6vuvNgQaKzSEkEa/b/UDjdbNTH/W6h5XWSZrtAm/FO94WgMxWR\n\tPj1lRvJfYcqdhk6ojE6RRrV/laxt7U4WFvzdovQ7ubeEUs0pHPa+R4YdBIISE5Iaq6Jh\n\tRR/g==","X-Gm-Message-State":"AHPjjUghz37+/XuhLoOhbKawEPp1SpRjwbusv2/9sG0GtsCMwduk1Ics\n\tQsiLr9OLh4nrhQ==","X-Google-Smtp-Source":"ADKCNb6xqh0zSof7Db2I0hVAuQcWaRVt9s4xtVMDdl52XfTSmNX2XhoE5n/gdccI40dpCPsSufJg9Q==","X-Received":"by 10.223.146.129 with SMTP id 1mr1865297wrn.1.1504596062404;\n\tTue, 05 Sep 2017 00:21:02 -0700 (PDT)","Date":"Tue, 5 Sep 2017 09:20:58 +0200","From":"Richard Cochran ","To":"Jesus Sanchez-Palencia ","Message-ID":"<20170905072058.giqnqfhcooqzc46w@localhost>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170901130311.v5nyx6e6gfats5dg@localhost>\n\t<1519366e-5418-4dda-db00-5bf50a1c67c4@intel.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<1519366e-5418-4dda-db00-5bf50a1c67c4@intel.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tVinicius Costa Gomes , netdev@vger.kernel.org, \n\tjhs@mojatatu.com, intel-wired-lan@lists.osuosl.org,\n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1764511,"web_url":"http://patchwork.ozlabs.org/comment/1764511/","msgid":"<20170907053411.GA6580@sisyphus.home.austad.us>","list_archive_url":null,"date":"2017-09-07T05:34:11","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":67212,"url":"http://patchwork.ozlabs.org/api/people/67212/","name":"Henrik Austad","email":"henrik@austad.us"},"content":"On Thu, Aug 31, 2017 at 06:26:20PM -0700, Vinicius Costa Gomes wrote:\n> Hi,\n> \n> This patchset is an RFC on a proposal of how the Traffic Control subsystem can\n> be used to offload the configuration of traffic shapers into network devices\n> that provide support for them in HW. Our goal here is to start upstreaming\n> support for features related to the Time-Sensitive Networking (TSN) set of\n> standards into the kernel.\n\nNice to see that others are working on this as well! :)\n\nA short disclaimer; I'm pretty much anchored in the view \"linux is the \nend-station in a TSN domain\", is this your approach as well, or are you \nlooking at this driver to be used in bridges as well? (because that will \naffect the comments on time-aware shaper and frame preemption)\n\nYet another disclaimer; I am not a linux networking subsystem expert. Not \nby a long shot! There are black magic happening in the internals of the \nnetworking subsystem that I am not even aware of. So if something I say or \nask does not make sense _at_all_, that's probably why..\n\nI do know a tiny bit about TSN though, and I have been messing around \nwith it for a little while, hence my comments below\n\n> As part of this work, we've assessed previous public discussions related to TSN\n> enabling: patches from Henrik Austad (Cisco), the presentation from Eric Mann\n> at Linux Plumbers 2012, patches from Gangfeng Huang (National Instruments) and\n> the current state of the OpenAVNU project (https://github.com/AVnu/OpenAvnu/).\n\n/me eyes Cc ;p\n\n> Overview\n> ========\n> \n> Time-sensitive Networking (TSN) is a set of standards that aim to address\n> resources availability for providing bandwidth reservation and bounded latency\n> on Ethernet based LANs. The proposal described here aims to cover mainly what is\n> needed to enable the following standards: 802.1Qat, 802.1Qav, 802.1Qbv and\n> 802.1Qbu.\n> \n> The initial target of this work is the Intel i210 NIC, but other controllers'\n> datasheet were also taken into account, like the Renesas RZ/A1H RZ/A1M group and\n> the Synopsis DesignWare Ethernet QoS controller.\n\nNXP has a TSN aware chip on the i.MX7 sabre board as well \n\n> Proposal\n> ========\n> \n> Feature-wise, what is covered here are configuration interfaces for HW\n> implementations of the Credit-Based shaper (CBS, 802.1Qav), Time-Aware shaper\n> (802.1Qbv) and Frame Preemption (802.1Qbu). CBS is a per-queue shaper, while\n> Qbv and Qbu must be configured per port, with the configuration covering all\n> queues. Given that these features are related to traffic shaping, and that the\n> traffic control subsystem already provides a queueing discipline that offloads\n> config into the device driver (i.e. mqprio), designing new qdiscs for the\n> specific purpose of offloading the config for each shaper seemed like a good\n> fit.\n\njust to be clear, you register sch_cbs as a subclass to mqprio, not as a \nroot class?\n\n> For steering traffic into the correct queues, we use the socket option\n> SO_PRIORITY and then a mechanism to map priority to traffic classes / Tx queues.\n> The qdisc mqprio is currently used in our tests.\n\nRight, fair enough, I'd prefer the TSN qdisc to be the root-device and \nrather have mqprio for high priority traffic and another for 'everything \nelse'', but this would work too. This is not that relevant at this stage I \nguess :)\n\n> As for the shapers config interface:\n> \n> * CBS (802.1Qav)\n> \n> This patchset is proposing a new qdisc called 'cbs'. Its 'tc' cmd line is:\n> $ tc qdisc add dev IFACE parent ID cbs locredit N hicredit M sendslope S \\\n> idleslope I\n\nSo this confuses me a bit, why specify sendSlope?\n\n sendSlope = portTransmitRate - idleSlope\n\nand portTransmitRate is the speed of the MAC (which you get from the \ndriver). Adding sendSlope here is just redundant I think.\n\nAlso, does this mean that when you create the qdisc, you have locked the \nbandwidth for the scheduler? Meaning, if I later want to add another \nstream that requires more bandwidth, I have to close all active streams, \nreconfigure the qdisc and then restart?\n\n> Note that the parameters for this qdisc are the ones defined by the\n> 802.1Q-2014 spec, so no hardware specific functionality is exposed here.\n\nYou do need to know if the link is brought up as 100 or 1000 though - which \nthe driver already knows.\n\n> * Time-aware shaper (802.1Qbv):\n> \n> The idea we are currently exploring is to add a \"time-aware\", priority based\n> qdisc, that also exposes the Tx queues available and provides a mechanism for\n> mapping priority <-> traffic class <-> Tx queues in a similar fashion as\n> mqprio. We are calling this qdisc 'taprio', and its 'tc' cmd line would be:\n\nAs far as I know, this is not supported by i210, and if time-aware shaping \nis enabled in the network - you'll be queued on a bridge until the window \nopens as time-aware shaping is enforced on the tx-port and not on rx. Is \nthis required in this driver?\n\n> $ $ tc qdisc add dev ens4 parent root handle 100 taprio num_tc 4 \\\n> \t map 2 2 1 0 3 3 3 3 3 3 3 3 3 3 3 3 \\\n> \t queues 0 1 2 3 \\\n> \t sched-file gates.sched [base-time ] \\\n> [cycle-time ] [extension-time ]\n\nThat was a lot of priorities! 802.1Q lists 8 priorities, where does these \n16 come from?\n\nYou map pri 0,1 to queue 2, pri 2 to queue 1 (Class B), pri 3 to queue 0 \n(class A) and everythign else to queue 3. This is what I would expect, \nexcept for the additional 8 priorities.\n\n> is multi-line, with each line being of the following format:\n> \n> \n> Qbv only defines one : \"S\" for 'SetGates'\n> \n> For example:\n> \n> S 0x01 300\n> S 0x03 500\n> \n> This means that there are two intervals, the first will have the gate\n> for traffic class 0 open for 300 nanoseconds, the second will have\n> both traffic classes open for 500 nanoseconds.\n\nAre you aware of any hw except dedicated switching stuff that supports \nthis? (meant as \"I'm curious and would like to know\")\n\n> Additionally, an option to set just one entry of the gate control list will\n> also be provided by 'taprio':\n> \n> $ tc qdisc (...) \\\n> sched-row \\\n> [base-time ] [cycle-time ] \\\n> [extension-time ]\n> \n> \n> * Frame Preemption (802.1Qbu):\n\nSo Frame preemption is nice, but my understanding of Qbu is that the real \nbenefit is at the bridges and not in the endpoints. As jumbo-frames is \nexplicitly disallowed in Qav, the maximum latency incurred by a frame in \nflight is 12us on a 1Gbps link. I am not sure if these 12us is what will be \nthe main delay in your application.\n\nOr have I missed some crucial point here?\n\n> To control even further the latency, it may prove useful to signal which\n> traffic classes are marked as preemptable. For that, 'taprio' provides the\n> preemption command so you set each traffic class as preemptable or not:\n> \n> $ tc qdisc (...) \\\n> preemption 0 1 1 1\n> \n> * Time-aware shaper + Preemption:\n> \n> As an example of how Qbv and Qbu can be used together, we may specify\n> both the schedule and the preempt-mask, and this way we may also\n> specify the Set-Gates-and-Hold and Set-Gates-and-Release commands as\n> specified in the Qbu spec:\n> \n> $ tc qdisc add dev ens4 parent root handle 100 taprio num_tc 4 \\\n> \t map 2 2 1 0 3 3 3 3 3 3 3 3 3 3 3 3 \\\n> \t queues 0 1 2 3 \\\n> \t preemption 0 1 1 1 \\\n> \t sched-file preempt_gates.sched\n> \n> is multi-line, with each line being of the following format:\n> \n> \n> For this case, two new commands are introduced:\n> \n> \"H\" for 'set gates and hold'\n> \"R\" for 'set gates and release'\n> \n> H 0x01 300\n> R 0x03 500\n\nSo my understanding of all of this is that you configure the *total* \nbandwith for each class when you load the qdisc and then let userspace \nhandle the rest. Is this correct?\n\nIn my view, it would be nice if the qdisc had some notion about streams so \nthat you could create a stream, feed frames to it and let the driver pace \nthem out. (The fewer you queue, the shorter the delay). This will also \nallow you to enforce per-stream bandwidth restrictions. I don't see how you \ncan do this here unless you want to do this in userspace.\n\nDo you have any plans for adding support for multiplexing streams? If you \nhave multiple streams, how do you enforce that one stream does not eat into \nthe bandwidth of another stream? AFAIK, this is something the network must \nenforce, but I see no option of doing som here.\n\n> Testing this RFC\n> ================\n> \n> For testing the patches of this RFC only, you can refer to the samples and\n> helper script being added to samples/tsn/ and the use the 'mqprio' qdisc to\n> setup the priorities to Tx queues mapping, together with the 'cbs' qdisc to\n> configure the HW shaper of the i210 controller:\n\nI will test it, feedback will be provided soon! :)\n\nThanks!\n-Henrik\n\n> 1) Setup priorities to traffic classes to hardware queues mapping\n> $ tc qdisc replace dev enp3s0 parent root mqprio num_tc 3 \\\n> map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@2 hw 0\n> \n> 2) Check scheme. You want to get the inner qdiscs ID from the bottom up\n> $ tc -g class show dev enp3s0\n> \n> Ex.:\n> +---(802a:3) mqprio\n> | +---(802a:6) mqprio\n> | +---(802a:7) mqprio\n> |\n> +---(802a:2) mqprio\n> | +---(802a:5) mqprio\n> |\n> +---(802a:1) mqprio\n> +---(802a:4) mqprio\n> \n> * Here '802a:4' is Tx Queue #0 and '802a:5' is Tx Queue #1.\n> \n> 3) Calculate CBS parameters for classes A and B. i.e. BW for A is 20Mbps and\n> for B is 10Mbps:\n> $ ./samples/tsn/calculate_cbs_params.py -A 20000 -a 1500 -B 10000 -b 1500\n> \n> 4) Configure CBS for traffic class A (priority 3) as provided by the script:\n> $ tc qdisc replace dev enp3s0 parent 802a:4 cbs locredit -1470 \\\n> hicredit 30 sendslope -980000 idleslope 20000\n> \n> 5) Configure CBS for traffic class B (priority 2):\n> $ tc qdisc replace dev enp3s0 parent 802a:5 cbs \\\n> locredit -1485 hicredit 31 sendslope -990000 idleslope 10000\n> \n> 6) Run Listener, compiled from samples/tsn/listener.c\n> $ ./listener -i enp3s0\n> \n> 7) Run Talker for class A (prio 3 here), compiled from samples/tsn/talker.c\n> $ ./talker -i enp3s0 -p 3\n> \n> * The bandwidth displayed on the listener output at this stage should be very\n> close to the one configured for class A.\n> \n> 8) You can also run a Talker for class B (prio 2 here)\n> $ ./talker -i enp3s0 -p 2\n> \n> * The bandwidth displayed on the listener output now should increase to very\n> close to the one configured for class A + class B.\n\nBecause you grab both class A *and* B, or because B will eat what A does \nnot use?\n\n-H\n\n> Authors\n> =======\n> - Andre Guedes \n> - Ivan Briano \n> - Jesus Sanchez-Palencia \n> - Vinicius Gomes \n> \n> \n> Andre Guedes (2):\n> igb: Add support for CBS offload\n> samples/tsn: Add script for calculating CBS config\n> \n> Jesus Sanchez-Palencia (1):\n> sample: Add TSN Talker and Listener examples\n> \n> Vinicius Costa Gomes (2):\n> net/sched: Introduce the user API for the CBS shaper\n> net/sched: Introduce Credit Based Shaper (CBS) qdisc\n> \n> drivers/net/ethernet/intel/igb/e1000_defines.h | 23 ++\n> drivers/net/ethernet/intel/igb/e1000_regs.h | 8 +\n> drivers/net/ethernet/intel/igb/igb.h | 6 +\n> drivers/net/ethernet/intel/igb/igb_main.c | 349 +++++++++++++++++++++++++\n> include/linux/netdevice.h | 1 +\n> include/uapi/linux/pkt_sched.h | 29 ++\n> net/sched/Kconfig | 11 +\n> net/sched/Makefile | 1 +\n> net/sched/sch_cbs.c | 286 ++++++++++++++++++++\n> samples/tsn/calculate_cbs_params.py | 112 ++++++++\n> samples/tsn/listener.c | 254 ++++++++++++++++++\n> samples/tsn/talker.c | 136 ++++++++++\n> 12 files changed, 1216 insertions(+)\n> create mode 100644 net/sched/sch_cbs.c\n> create mode 100755 samples/tsn/calculate_cbs_params.py\n> create mode 100644 samples/tsn/listener.c\n> create mode 100644 samples/tsn/talker.c\n> \n> --\n> 2.14.1","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=austad-us.20150623.gappssmtp.com\n\theader.i=@austad-us.20150623.gappssmtp.com\n\theader.b=\"fvoptvH0\"; dkim-atps=neutral"],"Received":["from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnq6r4kBlz9sNV\n\tfor ;\n\tThu, 7 Sep 2017 15:40:35 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id E73DF88869;\n\tThu, 7 Sep 2017 05:40:33 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id K1h-+IYI1NVK; Thu, 7 Sep 2017 05:40:31 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id D6CC8887F9;\n\tThu, 7 Sep 2017 05:40:31 +0000 (UTC)","from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id A234A1C0167\n\tfor ;\n\tThu, 7 Sep 2017 05:40:29 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id 962402FB97\n\tfor ;\n\tThu, 7 Sep 2017 05:40:29 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id DvwG5LBH-FjR for ;\n\tThu, 7 Sep 2017 05:40:27 +0000 (UTC)","from mail-lf0-f47.google.com (mail-lf0-f47.google.com\n\t[209.85.215.47])\n\tby silver.osuosl.org (Postfix) with ESMTPS id 292792F233\n\tfor ;\n\tThu, 7 Sep 2017 05:40:26 +0000 (UTC)","by mail-lf0-f47.google.com with SMTP id m199so22007429lfe.3\n\tfor ;\n\tWed, 06 Sep 2017 22:40:26 -0700 (PDT)","from sisyphus.home.austad.us (162.51-175-50.customer.lyse.net.\n\t[51.175.50.162]) by smtp.gmail.com with ESMTPSA id\n\th79sm272140ljh.27.2017.09.06.22.34.34\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 06 Sep 2017 22:34:34 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"delayed 00:05:49 by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=austad-us.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=/En6xBApUlWwKcLKrz22VgNJqflWbOGbadGiSRnkJAg=;\n\tb=fvoptvH004OPwIoFNANCx9biWgATIBq9W1zaOfX/wR2v7g//KNcZRAomYqQB7PyeWk\n\tbWjRkk2FTjZ2U/2nXPIkhfbXwywJg7nBX1/Lce/qyJgIwiQjVG1l9Z230ISXW9yMJ390\n\tiG3e/JitwWngJNcmoqs/T3yqfNq6ui7tz6N89Djnh6W24A8Aut7gFCZ+GdY6b1Ghhpj1\n\tcPqUKQvCq8x+TpWzvtrGQrmULtlPm9HJWPogQe81t0miR4wa/sZbtzzNi9h/I7zcGQ4d\n\t28awI5yp2IemZpESCCnOoNuC/ZEoo73Uj5D5u8W8nD2PWC63HZ9KwEoliElnH7azt4cD\n\tX3cQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=/En6xBApUlWwKcLKrz22VgNJqflWbOGbadGiSRnkJAg=;\n\tb=EpsAh+hFlphPfaugMcGJEpHusw7IVkUIpTBwY87IGpurh0bEqVANHtVEuKVp1lV4Fs\n\tfkvVjoxHA2x10gbO9DQKx3tcqzJSOKxGGDgqEACsJIi0KJ7fDTyTZUkO9iphVswhX7AH\n\t3Acf5WNIh7KkzP8fnKHlBmW53DAloqdhoxvi1wMBcvQwb/iM7EYxZDJPtxTLobfLlHzq\n\tH6q2eBRU7SBz26r9Zyu85JI7WRQ8694ftLsOZ7FsC/Zo462ObXUrhbnsi8tBWaawuzsS\n\tT05YdqK/nbQ/S0/pZ1i8Rz6rG0cpsoYk8zekofg37ajQmboVSQQDnRakmmPc9G6PWn90\n\tqmxQ==","X-Gm-Message-State":"AHPjjUjNumBGyk4lcISrebsBqwEYBjLNUmpWBFbA9+EKSnVodZd4he3J\n\tZ286k6YWDdA3gRkR","X-Google-Smtp-Source":"AOwi7QBK64/Gg36+zPVmmVhFAhbvqM+ILdNlU+iiF57xdp4eTLLyWHxekGwesuXLvKd4p6mxV0+J3w==","X-Received":"by 10.25.152.6 with SMTP id a6mr396442lfe.171.1504762475956;\n\tWed, 06 Sep 2017 22:34:35 -0700 (PDT)","Date":"Thu, 7 Sep 2017 07:34:11 +0200","From":"Henrik Austad ","To":"Vinicius Costa Gomes ","Message-ID":"<20170907053411.GA6580@sisyphus.home.austad.us>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>","MIME-Version":"1.0","In-Reply-To":"<20170901012625.14838-1-vinicius.gomes@intel.com>","User-Agent":"Mutt/1.5.24 (2015-08-30)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, richardcochran@gmail.com, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, boon.leong.ong@intel.com,\n\txiyou.wangcong@gmail.com, jesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"multipart/mixed;\n\tboundary=\"===============1010105122185342278==\"","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1764700,"web_url":"http://patchwork.ozlabs.org/comment/1764700/","msgid":"<20170907124018.deinzo3c4ice3q7n@localhost>","list_archive_url":null,"date":"2017-09-07T12:40:18","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":4009,"url":"http://patchwork.ozlabs.org/api/people/4009/","name":"Richard Cochran","email":"richardcochran@gmail.com"},"content":"On Thu, Sep 07, 2017 at 07:34:11AM +0200, Henrik Austad wrote:\n> Also, does this mean that when you create the qdisc, you have locked the \n> bandwidth for the scheduler? Meaning, if I later want to add another \n> stream that requires more bandwidth, I have to close all active streams, \n> reconfigure the qdisc and then restart?\n\nNo, just allocate enough bandwidth to accomodate all of the expected\nstreams. The streams can start and stop at will.\n\n> So my understanding of all of this is that you configure the *total* \n> bandwith for each class when you load the qdisc and then let userspace \n> handle the rest. Is this correct?\n\nNothing wrong with that.\n \n> In my view, it would be nice if the qdisc had some notion about streams so \n> that you could create a stream, feed frames to it and let the driver pace \n> them out. (The fewer you queue, the shorter the delay). This will also \n> allow you to enforce per-stream bandwidth restrictions. I don't see how you \n> can do this here unless you want to do this in userspace.\n> \n> Do you have any plans for adding support for multiplexing streams? If you \n> have multiple streams, how do you enforce that one stream does not eat into \n> the bandwidth of another stream? AFAIK, this is something the network must \n> enforce, but I see no option of doing som here.\n\nPlease, lets keep this simple. Today we have exactly zero user space\napplications using this kind of bandwidth reservation. The case of\nwanting the kernel to police individual stream usage does not exist,\nand probably never will.\n\nFor serious TSN use cases, the bandwidth needed by each system and\nindeed the entire network will be engineered, and we can reasonably\nexpect applications to cooperate in this regard.\n\nThanks,\nRichard","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.137; helo=fraxinus.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"dJDypSrd\"; dkim-atps=neutral"],"Received":["from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xp0RL0XXxz9t2M\n\tfor ;\n\tThu, 7 Sep 2017 22:40:28 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 4100887A80;\n\tThu, 7 Sep 2017 12:40:27 +0000 (UTC)","from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id bbB-SM7NyLBm; Thu, 7 Sep 2017 12:40:26 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 8AF2F87A6F;\n\tThu, 7 Sep 2017 12:40:26 +0000 (UTC)","from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id DFC121C039A\n\tfor ;\n\tThu, 7 Sep 2017 12:40:24 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id D639D30B8C\n\tfor ;\n\tThu, 7 Sep 2017 12:40:24 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id 00782Q6wkUGj for ;\n\tThu, 7 Sep 2017 12:40:24 +0000 (UTC)","from mail-wr0-f195.google.com (mail-wr0-f195.google.com\n\t[209.85.128.195])\n\tby silver.osuosl.org (Postfix) with ESMTPS id 2650630541\n\tfor ;\n\tThu, 7 Sep 2017 12:40:24 +0000 (UTC)","by mail-wr0-f195.google.com with SMTP id b9so4437858wra.0\n\tfor ;\n\tThu, 07 Sep 2017 05:40:24 -0700 (PDT)","from localhost (213-225-9-212.nat.highway.a1.net. [213.225.9.212])\n\tby smtp.gmail.com with ESMTPSA id\n\tq18sm1671999wre.4.2017.09.07.05.40.20\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tThu, 07 Sep 2017 05:40:21 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=xvswYt/nql4AFu7ps8U4Qgcfq3skrBePWjeahoDpoNI=;\n\tb=dJDypSrdz6YG178CXH6khKe76jrU8CLNPi0/eDOd+7q3G9tecIsTSan71W/cv5B/w4\n\tWd2HK8dJUGhjKMwL/5npkSv45Y0hO+ao4IvzNTAEjIxrem/C99y5EPBW/V55hSPNRw/3\n\t5qM78Jw0pFpXE7TCcnpS73PwQ8HLFlUU3aHmWCGaQnrIC3CjAQi6yjRZQjIqps2uw7Da\n\tgaYj3P7vGtTZxyb2MnlBOrZupbL2wBG0bCbev2MaQ/EMWib4gPRr+kZW5tUqRkXzLsyw\n\txe88DtRBJq3FTt3TzMXa608yaEIJFrEJPATU79gIAixA/SViDu9/3jkj2yp1vBRxbd8w\n\tRE1Q==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=xvswYt/nql4AFu7ps8U4Qgcfq3skrBePWjeahoDpoNI=;\n\tb=VRzGZO/ort3hQmrVY5P41IXa4505Gz2Apts5AA1uZD5+bd2bp3WSrjWtKWBz++e+dZ\n\tcFOwd8J1hpdaon0YHidlc1ijs2S7vpyOcJFqgfY1fIzKOPMHdDJ77Kfr55zmbSpBwoUG\n\tnZCyviI4+RB9fU35hv1cWMxawm7370Qrlja57M+Si9GIMd8rPYkt41XBG4ltf+h3+jtb\n\tq1J1OBMVDkFDchtH2sjQT+zUjoPI+Tt9qlbgCdQHxpfbY3EDQ88YG6qoPTVhLfVZz+Wq\n\tjzwmjMXOrh0mBMrTIjIFU2t2oj5epaSp3npFqdVxYHHJAfwFgkUeppxufzc0cOMdnH1s\n\thhHA==","X-Gm-Message-State":"AHPjjUiimHQqKHPGLDhVrXMBmKE0a8d1d5puJg6ydudr2TkIr0hZC+/c\n\tXyq3ymHa1K04xQ==","X-Google-Smtp-Source":"ADKCNb5ngaSFxfS6lLnrWQtou3cFpu0z7oRnDDj+YAKnB7yro2wyhsVqqUeI0q7EhESv6leFhc00sw==","X-Received":"by 10.223.147.39 with SMTP id 36mr1885474wro.175.1504788022463; \n\tThu, 07 Sep 2017 05:40:22 -0700 (PDT)","Date":"Thu, 7 Sep 2017 14:40:18 +0200","From":"Richard Cochran ","To":"Henrik Austad ","Message-ID":"<20170907124018.deinzo3c4ice3q7n@localhost>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170907053411.GA6580@sisyphus.home.austad.us>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20170907053411.GA6580@sisyphus.home.austad.us>","User-Agent":"NeoMutt/20170113 (1.7.2)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, \n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com,\n\tjesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1764787,"web_url":"http://patchwork.ozlabs.org/comment/1764787/","msgid":"<20170907152751.GA9064@sisyphus.home.austad.us>","list_archive_url":null,"date":"2017-09-07T15:27:51","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":67212,"url":"http://patchwork.ozlabs.org/api/people/67212/","name":"Henrik Austad","email":"henrik@austad.us"},"content":"On Thu, Sep 07, 2017 at 02:40:18PM +0200, Richard Cochran wrote:\n> On Thu, Sep 07, 2017 at 07:34:11AM +0200, Henrik Austad wrote:\n> > Also, does this mean that when you create the qdisc, you have locked the \n> > bandwidth for the scheduler? Meaning, if I later want to add another \n> > stream that requires more bandwidth, I have to close all active streams, \n> > reconfigure the qdisc and then restart?\n> \n> No, just allocate enough bandwidth to accomodate all of the expected\n> streams. The streams can start and stop at will.\n\nSure, that'll work.\n\nAnd if you want to this driver to act as a bridge, how do you accomodate \nchange in network requirements? (i.e. how does this work with switchdev?)\n- Or am I overthinking this?\n\n> > So my understanding of all of this is that you configure the *total* \n> > bandwith for each class when you load the qdisc and then let userspace \n> > handle the rest. Is this correct?\n> \n> Nothing wrong with that.\n\nDidn't mean to say it was wrong, just making sure I've understood the \nconcept.\n\n> > In my view, it would be nice if the qdisc had some notion about streams so \n> > that you could create a stream, feed frames to it and let the driver pace \n> > them out. (The fewer you queue, the shorter the delay). This will also \n> > allow you to enforce per-stream bandwidth restrictions. I don't see how you \n> > can do this here unless you want to do this in userspace.\n> > \n> > Do you have any plans for adding support for multiplexing streams? If you \n> > have multiple streams, how do you enforce that one stream does not eat into \n> > the bandwidth of another stream? AFAIK, this is something the network must \n> > enforce, but I see no option of doing som here.\n> \n> Please, lets keep this simple. \n\nSimple is always good\n\n> Today we have exactly zero user space\n> applications using this kind of bandwidth reservation. The case of\n> wanting the kernel to police individual stream usage does not exist,\n> and probably never will.\n\nThat we have *zero* userspace applications today is probably related to the \nfact that we have exacatly *zero* drivers in the kernel that talks TSN :)\n\nTo rephrase a bit, what I'm worried about:\n\nIf you have more than 1 application in userspace that wants to send data \nusing this scheduler, how do you ensure fair transmission of frames? (both \nhow much bandwidth they use, but also ordering of frames from each \napplication) Do you expect all of this to be handled in userspace?\n\n> For serious TSN use cases, the bandwidth needed by each system and\n> indeed the entire network will be engineered, and we can reasonably\n> expect applications to cooperate in this regard.\n\nyes.. that'll happen ;)\n\n> Thanks,\n> Richard\n\nDon't get me wrong, I think it is great that others are working on this!\nI'm just trying to fully understand the thought that have gone into this \nand how it is inteded to be used.\n\nI'll get busy testing the code and wrapping my head around the different \nparameters.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=austad-us.20150623.gappssmtp.com\n\theader.i=@austad-us.20150623.gappssmtp.com\n\theader.b=\"kj2l5P8n\"; dkim-atps=neutral"],"Received":["from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xp4931dTbz9t2r\n\tfor ;\n\tFri, 8 Sep 2017 01:28:23 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id A436D82C90;\n\tThu, 7 Sep 2017 15:28:21 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id m273tKl9hCBo; Thu, 7 Sep 2017 15:28:20 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id B3EFC82C9F;\n\tThu, 7 Sep 2017 15:28:20 +0000 (UTC)","from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\tby ash.osuosl.org (Postfix) with ESMTP id 5EDD91C0762\n\tfor ;\n\tThu, 7 Sep 2017 15:28:19 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 55D0282C9F\n\tfor ;\n\tThu, 7 Sep 2017 15:28:19 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id C1u5oz+xsjpt for ;\n\tThu, 7 Sep 2017 15:28:18 +0000 (UTC)","from mail-lf0-f66.google.com (mail-lf0-f66.google.com\n\t[209.85.215.66])\n\tby whitealder.osuosl.org (Postfix) with ESMTPS id 08C2982C90\n\tfor ;\n\tThu, 7 Sep 2017 15:28:17 +0000 (UTC)","by mail-lf0-f66.google.com with SMTP id c8so4564277lfe.2\n\tfor ;\n\tThu, 07 Sep 2017 08:28:17 -0700 (PDT)","from sisyphus.home.austad.us (162.51-175-50.customer.lyse.net.\n\t[51.175.50.162]) by smtp.gmail.com with ESMTPSA id\n\tp204sm440389lfp.29.2017.09.07.08.28.13\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 07 Sep 2017 08:28:13 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=austad-us.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=JukBqG5Rm9ygpm4LOiyanVEZov03WRp7qe43QDWS2QE=;\n\tb=kj2l5P8nAeTHB8Wx8vOvtFL5I8QEn0oZOaU19+U32C9INcD5LgcxacrzyT8V7SfJCw\n\tY1hvbGGMEgQCpMz+OtG/wVdy/eG0PNEd+diDaK9qLbu1RVxtVucK7btEd1W7seXTiiPQ\n\tFL21NIhs64hcKmVPjqvplgtGMTxjxdFEIBO65/PJa1LHrz4z4woDpfhS3bOxIWZg1iwD\n\tJc3q6x8zZZngqgBJAad00764pHrZXNqYhkf+Nk0EANFG3beBM44aS1wf4UfV8FTnAiCk\n\t3G7QzKEzzwnxOCLRod8556/9wpairgQN9vyZ/Z1QIFjQeWmxjx6EHZYKVNwo2YJ4PzKf\n\tgcrQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=JukBqG5Rm9ygpm4LOiyanVEZov03WRp7qe43QDWS2QE=;\n\tb=hOHoZWSasLkxpauelCElrRWTjHb7nLdHwih8Gc9pK5B8lQUACk6D9ltQUAhiOOaADE\n\tvg6d//ZMjOkAqbq22P+zcgx/cnOo/dJ+JxZB3F3lHbR1GloUsa6yc9bbrlQogPTbAc1Q\n\tzvP+a1pxueMuyGImCtsEovvE7AxM+jlnYJJqfpFjsmc/GohmOm0MdrCBOXECU0fi1TLL\n\tPY0DMeMcHqRRHcr5WjHVYDe35c0gRx26uvdB4oLI0gJaUKvoG3L4lCk8PmetTh0OlDrK\n\tIrzgq3/28rMaGZMajKwQr9rygsQg/Crd2ZBs5dxH/fknBJbjITaT4ZxVOAMH6/QBJGWu\n\tIG8w==","X-Gm-Message-State":"AHPjjUiNF6AhksDNVVnRzT9kxhVE2Kq+C/mZlDAr9nyG+M17jPiDHPlG\n\t7CTHxW8m9xSKqLLq","X-Google-Smtp-Source":"ADKCNb5xGlPEebq557h1FfpbtUHf3JssHpBsTI32ZTQEW0S7HLZ1NkkxXlb8Ta5I/MzTQO4mwxg2gg==","X-Received":"by 10.46.4.129 with SMTP id a1mr1323687ljf.6.1504798095268;\n\tThu, 07 Sep 2017 08:28:15 -0700 (PDT)","Date":"Thu, 7 Sep 2017 17:27:51 +0200","From":"Henrik Austad ","To":"Richard Cochran ","Message-ID":"<20170907152751.GA9064@sisyphus.home.austad.us>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170907053411.GA6580@sisyphus.home.austad.us>\n\t<20170907124018.deinzo3c4ice3q7n@localhost>","MIME-Version":"1.0","In-Reply-To":"<20170907124018.deinzo3c4ice3q7n@localhost>","User-Agent":"Mutt/1.5.24 (2015-08-30)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, \n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com,\n\tjesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"multipart/mixed;\n\tboundary=\"===============7778245832059178399==\"","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1764797,"web_url":"http://patchwork.ozlabs.org/comment/1764797/","msgid":"<20170907155315.5gqy5e4susl25wa2@localhost>","list_archive_url":null,"date":"2017-09-07T15:53:15","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":4009,"url":"http://patchwork.ozlabs.org/api/people/4009/","name":"Richard Cochran","email":"richardcochran@gmail.com"},"content":"On Thu, Sep 07, 2017 at 05:27:51PM +0200, Henrik Austad wrote:\n> On Thu, Sep 07, 2017 at 02:40:18PM +0200, Richard Cochran wrote:\n> And if you want to this driver to act as a bridge, how do you accomodate \n> change in network requirements? (i.e. how does this work with switchdev?)\n\nTo my understanding, this Qdisc idea provides QoS for the host's\ntransmitted traffic, and nothing more.\n\n> - Or am I overthinking this?\n\nBeing able to configure the external ports of a switchdev is probably\na nice feature, but that is another story. (But maybe I misunderstood\nthe authors' intent!)\n\n> If you have more than 1 application in userspace that wants to send data \n> using this scheduler, how do you ensure fair transmission of frames? (both \n> how much bandwidth they use,\n\nThere are many ways to handle this, and we shouldn't put any of that\npolicy into the kernel. For example, there might be a monolithic\napplication with configurable threads, or an allocation server that\ngrants bandwidth to applications via IPC, or a multiplexing stream\nserver like jack, pulse, etc, and so on...\n\n> but also ordering of frames from each application)\n\nNot sure what you mean by this.\n\n> Do you expect all of this to be handled in userspace?\n\nYes, I do.\n\nThanks,\nRichard","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.136; helo=silver.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"vG6Xf45Z\"; dkim-atps=neutral"],"Received":["from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xp4jy2HQWz9t2v\n\tfor ;\n\tFri, 8 Sep 2017 01:53:26 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id A924730526;\n\tThu, 7 Sep 2017 15:53:24 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id VuNsoROuQdFi; Thu, 7 Sep 2017 15:53:23 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby silver.osuosl.org (Postfix) with ESMTP id 6D5E2304C6;\n\tThu, 7 Sep 2017 15:53:23 +0000 (UTC)","from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\tby ash.osuosl.org (Postfix) with ESMTP id B2B1D1C26AC\n\tfor ;\n\tThu, 7 Sep 2017 15:53:22 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id A9FC288720\n\tfor ;\n\tThu, 7 Sep 2017 15:53:22 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id jBnmNpBDXpgA for ;\n\tThu, 7 Sep 2017 15:53:22 +0000 (UTC)","from mail-wr0-f179.google.com (mail-wr0-f179.google.com\n\t[209.85.128.179])\n\tby whitealder.osuosl.org (Postfix) with ESMTPS id E939C88765\n\tfor ;\n\tThu, 7 Sep 2017 15:53:21 +0000 (UTC)","by mail-wr0-f179.google.com with SMTP id v109so272282wrc.1\n\tfor ;\n\tThu, 07 Sep 2017 08:53:21 -0700 (PDT)","from localhost (213-225-9-212.nat.highway.a1.net. [213.225.9.212])\n\tby smtp.gmail.com with ESMTPSA id\n\tu128sm684760wmu.25.2017.09.07.08.53.18\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tThu, 07 Sep 2017 08:53:19 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=o0uIvRkWUvbEtdLyb023FP0YXlgh5Xr4aVF2kkTCqI4=;\n\tb=vG6Xf45ZdZ3QJNy/avAAeCIZV06D+WvK3i3PJcKzJTgVkJhG5riGI1BqvwNqFWBqac\n\tLjhLkxNmgbUMMixsTU+x8YIvxngz/aHi89L/oXiE81e/E/nGJ9rAPuodToBgEoeTjVvL\n\tzIKEXv5590gRyjvbCRSQHmns/oC303CwaozyUTYZzBbuXPSYnuzcgs9uWppS7RZKdNDB\n\tgH/vzx5olaILTlJ97/VI4vYVI9dtdE0CbfQ1Uz5/KAqea8nJBLb107bG1Yld+q30nC2F\n\tBJyqaOkSIM0f0oInlYG0wy5VTl6aRxDAjOq87q19CyAhIiJN0YOvYAkZqAIKPx8lOLeS\n\taiJg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=o0uIvRkWUvbEtdLyb023FP0YXlgh5Xr4aVF2kkTCqI4=;\n\tb=R08H2SAQSHOGAV/9yAbzY4bA8PynJVfCqUwdG63+xQvRGB1JgxddBwvsUB4GxyUu7a\n\tzvLlH63Z6EcydcANtI5r0RGi0GPgu+W6mfILlVDENHIYjhGYEpBlWfuhIHS+bH6fIy4R\n\tljZJl42VGvNDKvYdvQ3Vg9GGsMgVxDLEImZqZQvnB+Hmwol3LdCzbrT4mSeoM++Cl/6o\n\tBPNqRiBJDsQDZzUCZ//QR4JSObXnB9zk11VPbj1W6TeLsCXL2ljho21utwE+HIBs27zI\n\tv8NpzCpZ95nj9P78LKHX+P6KMTgb5O1braKOhUgVKxrqTMV7Mt39MUUq7qZpXBW9Ruyy\n\tJXlQ==","X-Gm-Message-State":"AHPjjUh9T3/0iU6rmImCse61hrDgiEmZeRC7GScrnsEoUYzVRFKqU2vJ\n\tNFqjPxiCeoMbBg==","X-Google-Smtp-Source":"ADKCNb5BFY4ciph/4ZFbXAYEQLC7teuemBQx+jA8/0/Jxi+cjGgXaZo5Z16TtJOpvHg+aI20z9QRgg==","X-Received":"by 10.223.134.174 with SMTP id 43mr2238348wrx.173.1504799600341; \n\tThu, 07 Sep 2017 08:53:20 -0700 (PDT)","Date":"Thu, 7 Sep 2017 17:53:15 +0200","From":"Richard Cochran ","To":"Henrik Austad ","Message-ID":"<20170907155315.5gqy5e4susl25wa2@localhost>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170907053411.GA6580@sisyphus.home.austad.us>\n\t<20170907124018.deinzo3c4ice3q7n@localhost>\n\t<20170907152751.GA9064@sisyphus.home.austad.us>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20170907152751.GA9064@sisyphus.home.austad.us>","User-Agent":"NeoMutt/20170113 (1.7.2)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, \n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com,\n\tjesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1764811,"web_url":"http://patchwork.ozlabs.org/comment/1764811/","msgid":"<20170907161838.GB9064@sisyphus.home.austad.us>","list_archive_url":null,"date":"2017-09-07T16:18:38","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":67212,"url":"http://patchwork.ozlabs.org/api/people/67212/","name":"Henrik Austad","email":"henrik@austad.us"},"content":"On Thu, Sep 07, 2017 at 05:53:15PM +0200, Richard Cochran wrote:\n> On Thu, Sep 07, 2017 at 05:27:51PM +0200, Henrik Austad wrote:\n> > On Thu, Sep 07, 2017 at 02:40:18PM +0200, Richard Cochran wrote:\n> > And if you want to this driver to act as a bridge, how do you accomodate \n> > change in network requirements? (i.e. how does this work with switchdev?)\n> \n> To my understanding, this Qdisc idea provides QoS for the host's\n> transmitted traffic, and nothing more.\n\nOk, then we're on the same page.\n\n> > - Or am I overthinking this?\n> \n> Being able to configure the external ports of a switchdev is probably\n> a nice feature, but that is another story. (But maybe I misunderstood\n> the authors' intent!)\n\nok, chalk that one up for later perhaps\n\n> > If you have more than 1 application in userspace that wants to send data \n> > using this scheduler, how do you ensure fair transmission of frames? (both \n> > how much bandwidth they use,\n> \n> There are many ways to handle this, and we shouldn't put any of that\n> policy into the kernel. For example, there might be a monolithic\n> application with configurable threads, or an allocation server that\n> grants bandwidth to applications via IPC, or a multiplexing stream\n> server like jack, pulse, etc, and so on...\n\ntrue\n\n> > but also ordering of frames from each application)\n> \n> Not sure what you mean by this.\n\nFair enough, I'm not that good at making myself clear :)\n\nLet's see if I can make a better attempt:\n\nIf you have 2 separate applications that have their own streams going to \ndifferent endpoints - but both are in the same class, then they will \nshare the qdisc bandwidth.\n\nSo application \n- A sends frame A1, A2, A3, .. An\n- B sends B1, B2, .. Bn\n\nWhat I was trying to describe was: if application A send 2 frames, and B \nsends 2 frames at the same time, then you would hope that the order would \nbe A1, B1, A2, B2, and not A1, A2, B1, B2.\n\nNone of this would be a problem if you expect a *single* user, like the \nallocation server you described above. Again, I think this is just me \noverthinking the problem right now :)\n\n> > Do you expect all of this to be handled in userspace?\n> \n> Yes, I do.\n\nok, fair enough\n\nThanks for answering my questions!","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=austad-us.20150623.gappssmtp.com\n\theader.i=@austad-us.20150623.gappssmtp.com\n\theader.b=\"BM+i5D+E\"; dkim-atps=neutral"],"Received":["from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xp5Hj55gLz9s78\n\tfor ;\n\tFri, 8 Sep 2017 02:19:13 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 6FFE388BB7;\n\tThu, 7 Sep 2017 16:19:11 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id MyjCepfDcpuW; Thu, 7 Sep 2017 16:19:10 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 9BA2188BAF;\n\tThu, 7 Sep 2017 16:19:10 +0000 (UTC)","from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id C666F1C3EC6\n\tfor ;\n\tThu, 7 Sep 2017 16:19:08 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id B535D30526\n\tfor ;\n\tThu, 7 Sep 2017 16:19:08 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id 3leqZLR-2ml1 for ;\n\tThu, 7 Sep 2017 16:19:05 +0000 (UTC)","from mail-lf0-f50.google.com (mail-lf0-f50.google.com\n\t[209.85.215.50])\n\tby silver.osuosl.org (Postfix) with ESMTPS id E9133304EB\n\tfor ;\n\tThu, 7 Sep 2017 16:19:04 +0000 (UTC)","by mail-lf0-f50.google.com with SMTP id q132so269878lfe.5\n\tfor ;\n\tThu, 07 Sep 2017 09:19:04 -0700 (PDT)","from sisyphus.home.austad.us (162.51-175-50.customer.lyse.net.\n\t[51.175.50.162]) by smtp.gmail.com with ESMTPSA id\n\tp204sm8277lfp.29.2017.09.07.09.19.00\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 07 Sep 2017 09:19:00 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=austad-us.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=TbV/AsA6fNmCGWy5TfVuw9t0BXihcVxBlzgwj8CKgnY=;\n\tb=BM+i5D+E0kgtnkx7MyDh7QLnTuaL+NtL7VaD0jFNG8UzAz0+P1BCYHtGlWDKv42wN3\n\twbEO+O6snWEeOCcu9KXXUq00+XIu3e4ElCQ8hF6rY64cy/lDgtnbhPxWkaZJvu+1t6+m\n\tTCZJPrNWToTh24BmVQl2v3v3MWqhEoxUh6duqdU6N4a9jam7KWaOFmPuvdJJnRhGvKn2\n\t+vpEoaRVI2J7oHGYm+WsqttCzZGGg6BDpQCCIpU6CT9XYK4vfXp7FGiY+KCQRzGXBVuw\n\tP7POCa/VjVX67uBJq6Wy8fH3OagMs4OVRdPn/Ddfvp4EJWl/1o4HHZt+yN5YB9+YWyNf\n\tpOfA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=TbV/AsA6fNmCGWy5TfVuw9t0BXihcVxBlzgwj8CKgnY=;\n\tb=VPPr9c8P6Up2IZbVVnBVIOwNXKPPoeV+133iqzKRgOHKr9CDu5PI170jz6jbriNCcC\n\tTQwOTTUV/fygz9gVy9os52ul5YzPZPyVgShES+lau/DGAj6Xr5M5MJdX4A7WF0o/MF2C\n\tjUBUEfU1h+CJqidjvucxoVauiqXEFytn4LjvK5T3JNDUHPrFM57uNGL1rRYnsHeYBbpV\n\txp1KNX7givyZQwWKOGm8YxkLRHj1YVvKHV4ZxLxjChIfNvx4ZW5vvIB45WqkdzMjIvH3\n\titWg/vLbdVCFmujDlKpj+pr4P7SI4hu/Z/OhF67ljH7SXVeI8PPYQD4iWTVZvW9obPK4\n\tyJHg==","X-Gm-Message-State":"AHPjjUgfHySxaik1Rc14IAPyQkskszAZHSjl+c+pYF0W3Bpgj6Hnpfm4\n\tm6ymaTQTRnKCw57e","X-Google-Smtp-Source":"ADKCNb6K6plVyNHVRxZIUPBoqJ3g2iQ3z6FS4pNJ9nK8SPSEEMga9CYrte5veqwZU6g5r2APdLIdIg==","X-Received":"by 10.46.21.2 with SMTP id s2mr1490241ljd.155.1504801142538;\n\tThu, 07 Sep 2017 09:19:02 -0700 (PDT)","Date":"Thu, 7 Sep 2017 18:18:38 +0200","From":"Henrik Austad ","To":"Richard Cochran ","Message-ID":"<20170907161838.GB9064@sisyphus.home.austad.us>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170907053411.GA6580@sisyphus.home.austad.us>\n\t<20170907124018.deinzo3c4ice3q7n@localhost>\n\t<20170907152751.GA9064@sisyphus.home.austad.us>\n\t<20170907155315.5gqy5e4susl25wa2@localhost>","MIME-Version":"1.0","In-Reply-To":"<20170907155315.5gqy5e4susl25wa2@localhost>","User-Agent":"Mutt/1.5.24 (2015-08-30)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, \n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com,\n\tjesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"multipart/mixed;\n\tboundary=\"===============6951145554211937234==\"","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1764947,"web_url":"http://patchwork.ozlabs.org/comment/1764947/","msgid":"<1504814332.2117.3.camel@intel.com>","list_archive_url":null,"date":"2017-09-07T19:58:53","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":72323,"url":"http://patchwork.ozlabs.org/api/people/72323/","name":"Andre Guedes","email":"andre.guedes@intel.com"},"content":"Hi Henrik,\n\nThanks for your feedback! I'll address some of your comments below.\n\nOn Thu, 2017-09-07 at 07:34 +0200, Henrik Austad wrote:\n> > As for the shapers config interface:\n> > \n> >  * CBS (802.1Qav)\n> > \n> >    This patchset is proposing a new qdisc called 'cbs'. Its 'tc' cmd line\n> > is:\n> >    $ tc qdisc add dev IFACE parent ID cbs locredit N hicredit M sendslope S\n> > \\\n> >      idleslope I\n> \n> So this confuses me a bit, why specify sendSlope?\n> \n>     sendSlope = portTransmitRate - idleSlope\n> \n> and portTransmitRate is the speed of the MAC (which you get from the \n> driver). Adding sendSlope here is just redundant I think.\n\nYes, this was something we've spent quite a few time discussing before this RFC\nseries. After reading the Annex L from 802.1Q-2014 (operation of CBS algorithm)\nso many times, we've came up with the rationale explained below.\n\nThe rationale here is that sendSlope is just another parameter from CBS\nalgorithm like idleSlope, hiCredit and loCredit. As such, its calculation\nshould be done at the same \"layer\" as the others parameters (in this case, user\nspace) in order to keep consistency. Moreover, in this design, the driver layer\nis dead simple: all the device driver has to do is applying CBS parameters to\nhardware. Having any CBS parameter calculation in the driver layer means all\ndevice drivers must implement that calculation.\n\n> Also, does this mean that when you create the qdisc, you have locked the \n> bandwidth for the scheduler? Meaning, if I later want to add another \n> stream that requires more bandwidth, I have to close all active streams, \n> reconfigure the qdisc and then restart?\n\nIf we want to reserve more bandwidth to \"accommodate\" a new stream, we don't\nneed to close all active streams. All we have to do is changing the CBS qdisc\nand pass the new CBS parameters. Here is what the command-line would look like:\n\n$ tc qdisc change dev enp0s4 parent 8001:5 cbs locredit -1470 hicredit 30\nsendslope -980000 idleslope 20000\n\nNo application/stream is interrupted while new CBS parameters are applied.\n\n> >    Note that the parameters for this qdisc are the ones defined by the\n> >    802.1Q-2014 spec, so no hardware specific functionality is exposed here.\n> \n> You do need to know if the link is brought up as 100 or 1000 though - which \n> the driver already knows.\n\nUser space knows that information via ethtool or /sys.\n\n> > Testing this RFC\n> > ================\n> > \n> > For testing the patches of this RFC only, you can refer to the samples and\n> > helper script being added to samples/tsn/ and the use the 'mqprio' qdisc to\n> > setup the priorities to Tx queues mapping, together with the 'cbs' qdisc to\n> > configure the HW shaper of the i210 controller:\n> \n> I will test it, feedback will be provided soon! :)\n\nThat's great! Please let us know if you find any issue and thanks for you\nsupport.\n\n> > 8) You can also run a Talker for class B (prio 2 here)\n> > $ ./talker -i enp3s0 -p 2\n> > \n> >  * The bandwidth displayed on the listener output now should increase to\n> > very\n> >    close to the one configured for class A + class B.\n> \n> Because you grab both class A *and* B, or because B will eat what A does \n> not use?\n\nBecause the listener application grabs both class A and B traffic.\n\nRegards,\n\nAndre","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","Received":["from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpCxD35Pnz9s3T\n\tfor ;\n\tFri, 8 Sep 2017 07:18:39 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 5A40E82250;\n\tThu, 7 Sep 2017 21:18:38 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id 6FvkOFFe3tQN; Thu, 7 Sep 2017 21:18:37 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 8096E82413;\n\tThu, 7 Sep 2017 21:18:37 +0000 (UTC)","from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\tby ash.osuosl.org (Postfix) with ESMTP id 220041C2922\n\tfor ;\n\tThu, 7 Sep 2017 19:58:58 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 1707988A49\n\tfor ;\n\tThu, 7 Sep 2017 19:58:58 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id WGpCzHXQh9tF for ;\n\tThu, 7 Sep 2017 19:58:57 +0000 (UTC)","from mga07.intel.com (mga07.intel.com [134.134.136.100])\n\tby whitealder.osuosl.org (Postfix) with ESMTPS id 01D7A82263\n\tfor ;\n\tThu, 7 Sep 2017 19:58:56 +0000 (UTC)","from fmsmga004.fm.intel.com ([10.253.24.48])\n\tby orsmga105.jf.intel.com with ESMTP; 07 Sep 2017 12:58:56 -0700","from fmsmsx108.amr.corp.intel.com ([10.18.124.206])\n\tby fmsmga004.fm.intel.com with ESMTP; 07 Sep 2017 12:58:56 -0700","from crsmsx104.amr.corp.intel.com (172.18.63.32) by\n\tFMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Thu, 7 Sep 2017 12:58:55 -0700","from crsmsx101.amr.corp.intel.com ([169.254.1.79]) by\n\tCRSMSX104.amr.corp.intel.com ([169.254.6.169]) with mapi id\n\t14.03.0319.002; Thu, 7 Sep 2017 13:58:54 -0600"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,360,1500966000\"; \n\td=\"p7s'?scan'208\";a=\"309211824\"","From":"\"Guedes, Andre\" ","To":"\"Gomes, Vinicius\" , \"henrik@austad.us\"\n\t","Thread-Topic":"[RFC net-next 0/5] TSN: Add qdisc-based config interfaces for\n\ttraffic shapers","Thread-Index":"AQHTIsFXBJrh9ZzKvESQZq1lqh2mraKpVPCAgADxlwA=","Date":"Thu, 7 Sep 2017 19:58:53 +0000","Message-ID":"<1504814332.2117.3.camel@intel.com>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170907053411.GA6580@sisyphus.home.austad.us>","In-Reply-To":"<20170907053411.GA6580@sisyphus.home.austad.us>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"yes","X-MS-TNEF-Correlator":"","x-originating-ip":"[10.24.9.18]","MIME-Version":"1.0","X-Mailman-Approved-At":"Thu, 07 Sep 2017 21:18:36 +0000","Cc":"\"jiri@resnulli.us\" , \"Briano,\n\tIvan\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"richardcochran@gmail.com\" ,\n\t\"jhs@mojatatu.com\" ,\n\t\"intel-wired-lan@lists.osuosl.org\" ,\n\t\"Ong, Boon Leong\" ,\n\t\"xiyou.wangcong@gmail.com\" ,\n\t\"Sanchez-Palencia, Jesus\" ","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"multipart/mixed;\n\tboundary=\"===============6418929685503930413==\"","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1764988,"web_url":"http://patchwork.ozlabs.org/comment/1764988/","msgid":"<1504821112.2117.8.camel@intel.com>","list_archive_url":null,"date":"2017-09-07T21:51:53","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":72323,"url":"http://patchwork.ozlabs.org/api/people/72323/","name":"Andre Guedes","email":"andre.guedes@intel.com"},"content":"On Thu, 2017-09-07 at 18:18 +0200, Henrik Austad wrote:\n> On Thu, Sep 07, 2017 at 05:53:15PM +0200, Richard Cochran wrote:\n> > On Thu, Sep 07, 2017 at 05:27:51PM +0200, Henrik Austad wrote:\n> > > On Thu, Sep 07, 2017 at 02:40:18PM +0200, Richard Cochran wrote:\n> > > And if you want to this driver to act as a bridge, how do you accomodate \n> > > change in network requirements? (i.e. how does this work with switchdev?)\n> > \n> > To my understanding, this Qdisc idea provides QoS for the host's\n> > transmitted traffic, and nothing more.\n> \n> Ok, then we're on the same page.\n> \n> > > - Or am I overthinking this?\n> > \n> > Being able to configure the external ports of a switchdev is probably\n> > a nice feature, but that is another story.  (But maybe I misunderstood\n> > the authors' intent!)\n> \n> ok, chalk that one up for later perhaps\n\nJust to clarify, we've been most focused on end-station use-cases. We've\nconsidered some bridge use-cases as well just to verify that the proposed\ndesign won't be an issue if someone else goes for it.\n\n- Andre","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","Received":["from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpFmg6yJFz9sDB\n\tfor ;\n\tFri, 8 Sep 2017 08:41:23 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 10C3088BA8;\n\tThu, 7 Sep 2017 22:41:22 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id 1jSFpWi2Ktsx; Thu, 7 Sep 2017 22:41:19 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id D1E6588A18;\n\tThu, 7 Sep 2017 22:41:19 +0000 (UTC)","from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id 5B7D61C1283\n\tfor ;\n\tThu, 7 Sep 2017 21:51:59 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id 5102B2F1B3\n\tfor ;\n\tThu, 7 Sep 2017 21:51:59 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id rB613c9SYwbO for ;\n\tThu, 7 Sep 2017 21:51:58 +0000 (UTC)","from mga04.intel.com (mga04.intel.com [192.55.52.120])\n\tby silver.osuosl.org (Postfix) with ESMTPS id A93E127E47\n\tfor ;\n\tThu, 7 Sep 2017 21:51:58 +0000 (UTC)","from orsmga004.jf.intel.com ([10.7.209.38])\n\tby fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t07 Sep 2017 14:51:58 -0700","from fmsmsx105.amr.corp.intel.com ([10.18.124.203])\n\tby orsmga004.jf.intel.com with ESMTP; 07 Sep 2017 14:51:57 -0700","from fmsmsx123.amr.corp.intel.com (10.18.125.38) by\n\tFMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Thu, 7 Sep 2017 14:51:57 -0700","from crsmsx102.amr.corp.intel.com (172.18.63.137) by\n\tfmsmsx123.amr.corp.intel.com (10.18.125.38) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Thu, 7 Sep 2017 14:51:57 -0700","from crsmsx101.amr.corp.intel.com ([169.254.1.79]) by\n\tCRSMSX102.amr.corp.intel.com ([169.254.2.58]) with mapi id\n\t14.03.0319.002; Thu, 7 Sep 2017 15:51:54 -0600"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,360,1500966000\"; \n\td=\"p7s'?scan'208\";a=\"126629440\"","From":"\"Guedes, Andre\" ","To":"\"richardcochran@gmail.com\" , \"henrik@austad.us\"\n\t","Thread-Topic":"[RFC net-next 0/5] TSN: Add qdisc-based config interfaces for\n\ttraffic shapers","Thread-Index":"AQHTIsFXBJrh9ZzKvESQZq1lqh2mraKpVPCAgAB3DgCAAC7QgIAABxmAgAAHFwCAAF0bAA==","Date":"Thu, 7 Sep 2017 21:51:53 +0000","Message-ID":"<1504821112.2117.8.camel@intel.com>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170907053411.GA6580@sisyphus.home.austad.us>\n\t<20170907124018.deinzo3c4ice3q7n@localhost>\n\t<20170907152751.GA9064@sisyphus.home.austad.us>\n\t<20170907155315.5gqy5e4susl25wa2@localhost>\n\t<20170907161838.GB9064@sisyphus.home.austad.us>","In-Reply-To":"<20170907161838.GB9064@sisyphus.home.austad.us>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"yes","X-MS-TNEF-Correlator":"","x-originating-ip":"[10.24.9.18]","MIME-Version":"1.0","X-Mailman-Approved-At":"Thu, 07 Sep 2017 22:41:18 +0000","Cc":"\"jiri@resnulli.us\" , \"Briano,\n\tIvan\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jhs@mojatatu.com\" ,\n\t\"intel-wired-lan@lists.osuosl.org\" ,\n\t\"Ong, Boon Leong\" ,\n\t\"xiyou.wangcong@gmail.com\" ,\n\t\"Sanchez-Palencia, Jesus\" ","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"multipart/mixed;\n\tboundary=\"===============5893354153004368100==\"","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1765033,"web_url":"http://patchwork.ozlabs.org/comment/1765033/","msgid":"<87k21am10j.fsf@intel.com>","list_archive_url":null,"date":"2017-09-08T01:29:00","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":72272,"url":"http://patchwork.ozlabs.org/api/people/72272/","name":"Vinicius Costa Gomes","email":"vinicius.gomes@intel.com"},"content":"Henrik Austad writes:\n\n> On Thu, Aug 31, 2017 at 06:26:20PM -0700, Vinicius Costa Gomes wrote:\n>> Hi,\n>>\n>> This patchset is an RFC on a proposal of how the Traffic Control subsystem can\n>> be used to offload the configuration of traffic shapers into network devices\n>> that provide support for them in HW. Our goal here is to start upstreaming\n>> support for features related to the Time-Sensitive Networking (TSN) set of\n>> standards into the kernel.\n>\n> Nice to see that others are working on this as well! :)\n>\n> A short disclaimer; I'm pretty much anchored in the view \"linux is the\n> end-station in a TSN domain\", is this your approach as well, or are you\n> looking at this driver to be used in bridges as well? (because that will\n> affect the comments on time-aware shaper and frame preemption)\n>\n> Yet another disclaimer; I am not a linux networking subsystem expert. Not\n> by a long shot! There are black magic happening in the internals of the\n> networking subsystem that I am not even aware of. So if something I say or\n> ask does not make sense _at_all_, that's probably why..\n>\n> I do know a tiny bit about TSN though, and I have been messing around\n> with it for a little while, hence my comments below\n>\n>> As part of this work, we've assessed previous public discussions related to TSN\n>> enabling: patches from Henrik Austad (Cisco), the presentation from Eric Mann\n>> at Linux Plumbers 2012, patches from Gangfeng Huang (National Instruments) and\n>> the current state of the OpenAVNU project (https://github.com/AVnu/OpenAvnu/).\n>\n> /me eyes Cc ;p\n>\n>> Overview\n>> ========\n>>\n>> Time-sensitive Networking (TSN) is a set of standards that aim to address\n>> resources availability for providing bandwidth reservation and bounded latency\n>> on Ethernet based LANs. The proposal described here aims to cover mainly what is\n>> needed to enable the following standards: 802.1Qat, 802.1Qav, 802.1Qbv and\n>> 802.1Qbu.\n>>\n>> The initial target of this work is the Intel i210 NIC, but other controllers'\n>> datasheet were also taken into account, like the Renesas RZ/A1H RZ/A1M group and\n>> the Synopsis DesignWare Ethernet QoS controller.\n>\n> NXP has a TSN aware chip on the i.MX7 sabre board as well \n\nCool. Will take a look.\n\n>\n>> Proposal\n>> ========\n>>\n>> Feature-wise, what is covered here are configuration interfaces for HW\n>> implementations of the Credit-Based shaper (CBS, 802.1Qav), Time-Aware shaper\n>> (802.1Qbv) and Frame Preemption (802.1Qbu). CBS is a per-queue shaper, while\n>> Qbv and Qbu must be configured per port, with the configuration covering all\n>> queues. Given that these features are related to traffic shaping, and that the\n>> traffic control subsystem already provides a queueing discipline that offloads\n>> config into the device driver (i.e. mqprio), designing new qdiscs for the\n>> specific purpose of offloading the config for each shaper seemed like a good\n>> fit.\n>\n> just to be clear, you register sch_cbs as a subclass to mqprio, not as a\n> root class?\n\nThat's right.\n\n>\n>> For steering traffic into the correct queues, we use the socket option\n>> SO_PRIORITY and then a mechanism to map priority to traffic classes / Tx queues.\n>> The qdisc mqprio is currently used in our tests.\n>\n> Right, fair enough, I'd prefer the TSN qdisc to be the root-device and\n> rather have mqprio for high priority traffic and another for 'everything\n> else'', but this would work too. This is not that relevant at this stage I\n> guess :)\n\nThat's a scenario I haven't considered, will give it some thought.\n\n>\n>> As for the shapers config interface:\n>>\n>> * CBS (802.1Qav)\n>>\n>> This patchset is proposing a new qdisc called 'cbs'. Its 'tc' cmd line is:\n>> $ tc qdisc add dev IFACE parent ID cbs locredit N hicredit M sendslope S \\\n>> idleslope I\n>\n> So this confuses me a bit, why specify sendSlope?\n>\n> sendSlope = portTransmitRate - idleSlope\n>\n> and portTransmitRate is the speed of the MAC (which you get from the\n> driver). Adding sendSlope here is just redundant I think.\n>\n> Also, does this mean that when you create the qdisc, you have locked the\n> bandwidth for the scheduler? Meaning, if I later want to add another\n> stream that requires more bandwidth, I have to close all active streams,\n> reconfigure the qdisc and then restart?\n>\n>> Note that the parameters for this qdisc are the ones defined by the\n>> 802.1Q-2014 spec, so no hardware specific functionality is exposed here.\n>\n> You do need to know if the link is brought up as 100 or 1000 though - which\n> the driver already knows.\n>\n>> * Time-aware shaper (802.1Qbv):\n>>\n>> The idea we are currently exploring is to add a \"time-aware\", priority based\n>> qdisc, that also exposes the Tx queues available and provides a mechanism for\n>> mapping priority <-> traffic class <-> Tx queues in a similar fashion as\n>> mqprio. We are calling this qdisc 'taprio', and its 'tc' cmd line would be:\n>\n> As far as I know, this is not supported by i210, and if time-aware shaping\n> is enabled in the network - you'll be queued on a bridge until the window\n> opens as time-aware shaping is enforced on the tx-port and not on rx. Is\n> this required in this driver?\n\nYeah, i210 doesn't support the time-aware shaper. I think the second\npart of your question doesn't really apply, then.\n\n>\n>> $ $ tc qdisc add dev ens4 parent root handle 100 taprio num_tc 4 \\\n>> \t map 2 2 1 0 3 3 3 3 3 3 3 3 3 3 3 3 \\\n>> \t queues 0 1 2 3 \\\n>> \t sched-file gates.sched [base-time ] \\\n>> [cycle-time ] [extension-time ]\n>\n> That was a lot of priorities! 802.1Q lists 8 priorities, where does these\n> 16 come from?\n\nEven if the 802.1Q only defines 8 priorities, the Linux network stack\nsupports a lot more (and this command line is more than slightly\ninspired by the mqprio equivalent).\n\n>\n> You map pri 0,1 to queue 2, pri 2 to queue 1 (Class B), pri 3 to queue 0\n> (class A) and everythign else to queue 3. This is what I would expect,\n> except for the additional 8 priorities.\n>\n>> is multi-line, with each line being of the following format:\n>> \n>>\n>> Qbv only defines one : \"S\" for 'SetGates'\n>>\n>> For example:\n>>\n>> S 0x01 300\n>> S 0x03 500\n>>\n>> This means that there are two intervals, the first will have the gate\n>> for traffic class 0 open for 300 nanoseconds, the second will have\n>> both traffic classes open for 500 nanoseconds.\n>\n> Are you aware of any hw except dedicated switching stuff that supports\n> this? (meant as \"I'm curious and would like to know\")\n\nNot really. I couldn't find any public documentation about products\ndestined for end stations that support this. I, too, would like to know\nmore.\n\n>\n>> Additionally, an option to set just one entry of the gate control list will\n>> also be provided by 'taprio':\n>>\n>> $ tc qdisc (...) \\\n>> sched-row \\\n>> [base-time ] [cycle-time ] \\\n>> [extension-time ]\n>>\n>>\n>> * Frame Preemption (802.1Qbu):\n>\n> So Frame preemption is nice, but my understanding of Qbu is that the real\n> benefit is at the bridges and not in the endpoints. As jumbo-frames is\n> explicitly disallowed in Qav, the maximum latency incurred by a frame in\n> flight is 12us on a 1Gbps link. I am not sure if these 12us is what will be\n> the main delay in your application.\n>\n> Or have I missed some crucial point here?\n\n\nYou didn't seem to have missed anything. What I saw as the biggest point\nfor frame preemption, is when it is used with scheduled traffic, you\ncould keep the preemptable traffic classes gates always open, have a few\ntime windows for periodic traffic, and still have predictable behaviour\nfor an unscheduled \"emergency\" traffic.\n\n\nCheers,\n--\nVinicius","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","Received":["from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpKVF0PWDz9sBZ\n\tfor ;\n\tFri, 8 Sep 2017 11:29:07 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id E251B88B85;\n\tFri, 8 Sep 2017 01:29:05 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id s37xpbQlFKOo; Fri, 8 Sep 2017 01:29:04 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 7962588B59;\n\tFri, 8 Sep 2017 01:29:04 +0000 (UTC)","from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\tby ash.osuosl.org (Postfix) with ESMTP id 906751C26AC\n\tfor ;\n\tFri, 8 Sep 2017 01:29:02 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id 8293689FE9\n\tfor ;\n\tFri, 8 Sep 2017 01:29:02 +0000 (UTC)","from hemlock.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id UgSokynHo+-3 for ;\n\tFri, 8 Sep 2017 01:29:01 +0000 (UTC)","from mga07.intel.com (mga07.intel.com [134.134.136.100])\n\tby hemlock.osuosl.org (Postfix) with ESMTPS id 4578189FE7\n\tfor ;\n\tFri, 8 Sep 2017 01:29:01 +0000 (UTC)","from fmsmga006.fm.intel.com ([10.253.24.20])\n\tby orsmga105.jf.intel.com with ESMTP; 07 Sep 2017 18:29:00 -0700","from ellie.jf.intel.com (HELO ellie) ([10.24.9.12])\n\tby fmsmga006.fm.intel.com with ESMTP; 07 Sep 2017 18:29:00 -0700"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,360,1500966000\"; d=\"scan'208\";a=\"149490350\"","From":"Vinicius Costa Gomes ","To":"Henrik Austad ","In-Reply-To":"<20170907053411.GA6580@sisyphus.home.austad.us>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170907053411.GA6580@sisyphus.home.austad.us>","User-Agent":"Notmuch/0.21 (http://notmuchmail.org) Emacs/25.1.1\n\t(x86_64-pc-linux-gnu)","Date":"Thu, 07 Sep 2017 18:29:00 -0700","Message-ID":"<87k21am10j.fsf@intel.com>","MIME-Version":"1.0","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, richardcochran@gmail.com, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, boon.leong.ong@intel.com,\n\txiyou.wangcong@gmail.com, jesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1765096,"web_url":"http://patchwork.ozlabs.org/comment/1765096/","msgid":"<20170908060623.GC9064@sisyphus.home.austad.us>","list_archive_url":null,"date":"2017-09-08T06:06:23","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":67212,"url":"http://patchwork.ozlabs.org/api/people/67212/","name":"Henrik Austad","email":"henrik@austad.us"},"content":"On Thu, Sep 07, 2017 at 07:58:53PM +0000, Guedes, Andre wrote:\n> Hi Henrik,\n> \n> Thanks for your feedback! I'll address some of your comments below.\n> \n> On Thu, 2017-09-07 at 07:34 +0200, Henrik Austad wrote:\n> > > As for the shapers config interface:\n> > > \n> > >  * CBS (802.1Qav)\n> > > \n> > >    This patchset is proposing a new qdisc called 'cbs'. Its 'tc' cmd line\n> > > is:\n> > >    $ tc qdisc add dev IFACE parent ID cbs locredit N hicredit M sendslope S\n> > > \\\n> > >      idleslope I\n> > \n> > So this confuses me a bit, why specify sendSlope?\n> > \n> >     sendSlope = portTransmitRate - idleSlope\n> > \n> > and portTransmitRate is the speed of the MAC (which you get from the \n> > driver). Adding sendSlope here is just redundant I think.\n> \n> Yes, this was something we've spent quite a few time discussing before this RFC\n> series. After reading the Annex L from 802.1Q-2014 (operation of CBS algorithm)\n> so many times, we've came up with the rationale explained below.\n> \n> The rationale here is that sendSlope is just another parameter from CBS\n> algorithm like idleSlope, hiCredit and loCredit. As such, its calculation\n> should be done at the same \"layer\" as the others parameters (in this case, user\n> space) in order to keep consistency. Moreover, in this design, the driver layer\n> is dead simple: all the device driver has to do is applying CBS parameters to\n> hardware. Having any CBS parameter calculation in the driver layer means all\n> device drivers must implement that calculation.\n\nOk, that actually makes a lot of sense, and anything that keeps this kind \nof arithmetic outside the kernel is a good thing!\n\nThanks for the clarification!\n\n> > Also, does this mean that when you create the qdisc, you have locked the \n> > bandwidth for the scheduler? Meaning, if I later want to add another \n> > stream that requires more bandwidth, I have to close all active streams, \n> > reconfigure the qdisc and then restart?\n> \n> If we want to reserve more bandwidth to \"accommodate\" a new stream, we don't\n> need to close all active streams. All we have to do is changing the CBS qdisc\n> and pass the new CBS parameters. Here is what the command-line would look like:\n> \n> $ tc qdisc change dev enp0s4 parent 8001:5 cbs locredit -1470 hicredit 30\n> sendslope -980000 idleslope 20000\n> \n> No application/stream is interrupted while new CBS parameters are applied.\n\nAh, good.\n\n> > >    Note that the parameters for this qdisc are the ones defined by the\n> > >    802.1Q-2014 spec, so no hardware specific functionality is exposed here.\n> > \n> > You do need to know if the link is brought up as 100 or 1000 though - which \n> > the driver already knows.\n> \n> User space knows that information via ethtool or /sys.\n\nFair point.\n\n> > > Testing this RFC\n> > > ================\n> > > \n> > > For testing the patches of this RFC only, you can refer to the samples and\n> > > helper script being added to samples/tsn/ and the use the 'mqprio' qdisc to\n> > > setup the priorities to Tx queues mapping, together with the 'cbs' qdisc to\n> > > configure the HW shaper of the i210 controller:\n> > \n> > I will test it, feedback will be provided soon! :)\n> \n> That's great! Please let us know if you find any issue and thanks for you\n> support.\n> \n> > > 8) You can also run a Talker for class B (prio 2 here)\n> > > $ ./talker -i enp3s0 -p 2\n> > > \n> > >  * The bandwidth displayed on the listener output now should increase to\n> > > very\n> > >    close to the one configured for class A + class B.\n> > \n> > Because you grab both class A *and* B, or because B will eat what A does \n> > not use?\n> \n> Because the listener application grabs both class A and B traffic.\n\nRight, got it.\n\nThanks for the feedback, I'm getting really excited about this! :D","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.136; helo=silver.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=austad-us.20150623.gappssmtp.com\n\theader.i=@austad-us.20150623.gappssmtp.com\n\theader.b=\"DP/SszR4\"; dkim-atps=neutral"],"Received":["from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpRfn4FDgz9sBZ\n\tfor ;\n\tFri, 8 Sep 2017 16:06:56 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id DAE062F77E;\n\tFri, 8 Sep 2017 06:06:53 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id DBZsDSN38fv9; Fri, 8 Sep 2017 06:06:52 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby silver.osuosl.org (Postfix) with ESMTP id AE9DC2F7A1;\n\tFri, 8 Sep 2017 06:06:52 +0000 (UTC)","from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id 17D151CEB72\n\tfor ;\n\tFri, 8 Sep 2017 06:06:52 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id 0CF462F7A1\n\tfor ;\n\tFri, 8 Sep 2017 06:06:52 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id Cb+qQP7fcsKL for ;\n\tFri, 8 Sep 2017 06:06:50 +0000 (UTC)","from mail-lf0-f49.google.com (mail-lf0-f49.google.com\n\t[209.85.215.49])\n\tby silver.osuosl.org (Postfix) with ESMTPS id 7F1A92F77E\n\tfor ;\n\tFri, 8 Sep 2017 06:06:50 +0000 (UTC)","by mail-lf0-f49.google.com with SMTP id 80so3395123lfy.4\n\tfor ;\n\tThu, 07 Sep 2017 23:06:50 -0700 (PDT)","from sisyphus.home.austad.us (162.51-175-50.customer.lyse.net.\n\t[51.175.50.162]) by smtp.gmail.com with ESMTPSA id\n\tj29sm174628ljb.44.2017.09.07.23.06.45\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 07 Sep 2017 23:06:46 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=austad-us.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=+SfOjWv6Fqpf5YFCUglOCKAuq3P3eRQr71GQEl8brHY=;\n\tb=DP/SszR40JXWcFhdOjUUvdrJxfmynniLRtKkmieUfW7pnUtgvgXmWCNt5QsCVlrHpf\n\tFGSTb94l46xQuBaHzdiQcACKAaKO9HwlpEheRykzyqBBbyfR95TT7nNWsbePSMUSyjmH\n\tXffuE5qTTXD5otHJQW9KGmzHxTCgsrEIO/A/xDLy408BXQt95W8EJab1lvz2wpB1kRcS\n\tuBXCnFa+WNNJakymvUk/wi68S6uWycQxQFucfIVQDbpzMWWVRJNtnQ9u/fQox67qxqZ4\n\tM5SI8W7SGbJ1e5libWAz3RgE6CGvLsWuOzW7Yi8yGUaLT+Fc87xurQQrKho0WYRfPcQg\n\tYwRg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=+SfOjWv6Fqpf5YFCUglOCKAuq3P3eRQr71GQEl8brHY=;\n\tb=kKjUq37aYL4BLSaer5r7an8cuLw9tr7SMFsjaWiJi3amGBvDadktxovTn/i03N3t6B\n\tCx/0flXLpm0GTYXo90e9V/JpLMrTBjeTcvjW2XQUffwRfLTyx7/sWzb64TdFH/xZ0GsZ\n\tAJbI97iHbJlZ6gy73fWQVb+osjewcvN08iLISsAnsK/6r5eMNOS5fWPJ+dssuPUA98nA\n\tkZApag3QNQYQQG1v8BwOzp2oDWghThlMfuZfiJxKp9fz6VO1Qwf9YFFtbbcgNe2O71t0\n\tfTp5WH8FzYNCZEQjp/luSAnRVRp9hug16zFmJi0YdEbQYcWnY6gthC/V4+XyRjB+F4al\n\tBcEA==","X-Gm-Message-State":"AHPjjUg+9k+3zkWQCqze1FIdrQSRGhD4TjBE7z75SxpvZTUJ7IzP5GxU\n\tnekI7SvzxnMxSsOL","X-Google-Smtp-Source":"ADKCNb6qHNWKR0Kl7t+VPqQRl0nS5MY7B14hIBKjjUfF1Edpe6w0HdEGEg7EsbMuIehftPqz6NeM7g==","X-Received":"by 10.46.1.226 with SMTP id f95mr615354lji.194.1504850807950;\n\tThu, 07 Sep 2017 23:06:47 -0700 (PDT)","Date":"Fri, 8 Sep 2017 08:06:23 +0200","From":"Henrik Austad ","To":"\"Guedes, Andre\" ","Message-ID":"<20170908060623.GC9064@sisyphus.home.austad.us>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170907053411.GA6580@sisyphus.home.austad.us>\n\t<1504814332.2117.3.camel@intel.com>","MIME-Version":"1.0","In-Reply-To":"<1504814332.2117.3.camel@intel.com>","User-Agent":"Mutt/1.5.24 (2015-08-30)","Cc":"\"jiri@resnulli.us\" , \"Briano,\n\tIvan\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"richardcochran@gmail.com\" ,\n\t\"jhs@mojatatu.com\" ,\n\t\"intel-wired-lan@lists.osuosl.org\" ,\n\t\"Ong, Boon Leong\" ,\n\t\"xiyou.wangcong@gmail.com\" ,\n\t\"Sanchez-Palencia, Jesus\" ","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"multipart/mixed;\n\tboundary=\"===============7358414223538544495==\"","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1766679,"web_url":"http://patchwork.ozlabs.org/comment/1766679/","msgid":"<20170912045644.aqujy7pyc2ugsaa4@localhost>","list_archive_url":null,"date":"2017-09-12T04:56:44","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":4009,"url":"http://patchwork.ozlabs.org/api/people/4009/","name":"Richard Cochran","email":"richardcochran@gmail.com"},"content":"On Thu, Sep 07, 2017 at 06:29:00PM -0700, Vinicius Costa Gomes wrote:\n> >> * Time-aware shaper (802.1Qbv):\n> >>\n> >> The idea we are currently exploring is to add a \"time-aware\", priority based\n> >> qdisc, that also exposes the Tx queues available and provides a mechanism for\n> >> mapping priority <-> traffic class <-> Tx queues in a similar fashion as\n> >> mqprio. We are calling this qdisc 'taprio', and its 'tc' cmd line would be:\n> >\n> > As far as I know, this is not supported by i210, and if time-aware shaping\n> > is enabled in the network - you'll be queued on a bridge until the window\n> > opens as time-aware shaping is enforced on the tx-port and not on rx. Is\n> > this required in this driver?\n> \n> Yeah, i210 doesn't support the time-aware shaper. I think the second\n> part of your question doesn't really apply, then.\n\nActually, you can implement 802.1Qbv (as an end station) quite easily\nusing the i210. I'll show how by posting a series after net-next\nopens up again.\n\nThanks,\nRichard","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"P7gExgVX\"; dkim-atps=neutral"],"Received":["from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xrsw95wLXz9s7B\n\tfor ;\n\tTue, 12 Sep 2017 14:56:56 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 3DD1687D2D;\n\tTue, 12 Sep 2017 04:56:54 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id KiAY72x6SIq7; Tue, 12 Sep 2017 04:56:52 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id DF2D687D13;\n\tTue, 12 Sep 2017 04:56:52 +0000 (UTC)","from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\tby ash.osuosl.org (Postfix) with ESMTP id 9ACDC1CEB4F\n\tfor ;\n\tTue, 12 Sep 2017 04:56:51 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id 9540489411\n\tfor ;\n\tTue, 12 Sep 2017 04:56:51 +0000 (UTC)","from hemlock.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id 9QVUl5lylHW1 for ;\n\tTue, 12 Sep 2017 04:56:51 +0000 (UTC)","from mail-wm0-f53.google.com (mail-wm0-f53.google.com\n\t[74.125.82.53])\n\tby hemlock.osuosl.org (Postfix) with ESMTPS id DF06789273\n\tfor ;\n\tTue, 12 Sep 2017 04:56:50 +0000 (UTC)","by mail-wm0-f53.google.com with SMTP id i189so52709483wmf.1\n\tfor ;\n\tMon, 11 Sep 2017 21:56:50 -0700 (PDT)","from localhost (213-225-12-121.nat.highway.a1.net.\n\t[213.225.12.121]) by smtp.gmail.com with ESMTPSA id\n\td82sm8754930wmd.14.2017.09.11.21.56.47\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tMon, 11 Sep 2017 21:56:48 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=vZeV8Peu6GRe4gftxR1PnprVKCMaYh98n+hZUXeNwaI=;\n\tb=P7gExgVXdb4TSKrJrrUa267leNTIoU0hDc0SbP8rYHXu6im0lVz4ktb1I6K0h9jbf1\n\t4EonxgyuGQzfyVeH2ndycumNJbWZf6kHIS4HY3OwmlzsVOfu1TC/TE47sdWGVfFigmTX\n\tQGzOXRdhMw1/GDyMVP8yzATnmK1E3acNx11S0C7z588Xv0mM8lv6IjY5WrQxqyB8j+Qt\n\t0mywaabk6UJylBaj7SS+UwC4En83cCBUv6y7f+IPuLjlOxQdEfYsnvuW+XFlXT76CvJW\n\tmaX0QV9eEKYdHd0xnS2OpjAnbkGaezgzygRQO1bHVCZ+dON3IXQ/nqbrDSB5fFcRUb1X\n\tFJ0A==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=vZeV8Peu6GRe4gftxR1PnprVKCMaYh98n+hZUXeNwaI=;\n\tb=A1LFkqAukSwMSIAp25ZZZLQiVLDkKWC9lYg5Fwc9SC/vjwS2c6bu7ZzU5R/SuExvT6\n\tUmMrBwuEQV9VNyGT5R+3Uq2WYdBZE2QDuMekSI8obTKzIrJpg01cv5/ONP0IQqsleS56\n\tYWMzQrY98KZ3eTibWMbFiBoZ3EpM7vSSyoMBWK0ihp0RTDFw1I8zPT6V2z85rPWXUDTE\n\tJVKqvoKG1iCCu/HfArkX2AtQZJ6fOYeC290u4BWvamEk0YdN7VPe1fkuYjvKZ/ElXbuA\n\tnzMYOBOf6U3yLAVnmn7cpUudIClpFesGcMPEE4w8LmP8a7N2TIVMPdGnmMYF+c3TYM9Z\n\tQU1w==","X-Gm-Message-State":"AHPjjUhQd9ZUV/W/sL8PQ94QkgyvhpZKb4SpPxeqLmlfH2FYmTAdmTUN\n\ty8euQ9QDv+A05g==","X-Google-Smtp-Source":"AOwi7QCjoFGFpSnJmNKYPlQibcMRQa3XmM4Nwaz8cvrMdnC1GzO5LxfTWbxtIfCMuRnNEsrytPY38A==","X-Received":"by 10.28.152.70 with SMTP id a67mr8788073wme.132.1505192209181; \n\tMon, 11 Sep 2017 21:56:49 -0700 (PDT)","Date":"Tue, 12 Sep 2017 06:56:44 +0200","From":"Richard Cochran ","To":"Vinicius Costa Gomes ","Message-ID":"<20170912045644.aqujy7pyc2ugsaa4@localhost>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170907053411.GA6580@sisyphus.home.austad.us>\n\t<87k21am10j.fsf@intel.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<87k21am10j.fsf@intel.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, Henrik Austad ,\n\tjhs@mojatatu.com, \n\tintel-wired-lan@lists.osuosl.org, boon.leong.ong@intel.com,\n\txiyou.wangcong@gmail.com, jesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1769945,"web_url":"http://patchwork.ozlabs.org/comment/1769945/","msgid":"<20170918080214.yrejz67wwnp2pjzf@localhost>","list_archive_url":null,"date":"2017-09-18T08:02:14","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":4009,"url":"http://patchwork.ozlabs.org/api/people/4009/","name":"Richard Cochran","email":"richardcochran@gmail.com"},"content":"On Thu, Aug 31, 2017 at 06:26:20PM -0700, Vinicius Costa Gomes wrote:\n> * Time-aware shaper (802.1Qbv):\n\nI just posted a working alternative showing how to handle 802.1Qbv and\nmany other Ethernet field buses.\n \n> The idea we are currently exploring is to add a \"time-aware\", priority based\n> qdisc, that also exposes the Tx queues available and provides a mechanism for\n> mapping priority <-> traffic class <-> Tx queues in a similar fashion as\n> mqprio. We are calling this qdisc 'taprio', and its 'tc' cmd line would be:\n> \n> $ $ tc qdisc add dev ens4 parent root handle 100 taprio num_tc 4 \\\n> \t map 2 2 1 0 3 3 3 3 3 3 3 3 3 3 3 3 \\\n> \t queues 0 1 2 3 \\\n> \t sched-file gates.sched [base-time ] \\\n> [cycle-time ] [extension-time ]\n> \n> is multi-line, with each line being of the following format:\n> \n> \n> Qbv only defines one : \"S\" for 'SetGates'\n> \n> For example:\n> \n> S 0x01 300\n> S 0x03 500\n> \n> This means that there are two intervals, the first will have the gate\n> for traffic class 0 open for 300 nanoseconds, the second will have\n> both traffic classes open for 500 nanoseconds.\n\nThe idea of the schedule file will not work in practice. Consider the\nfact that the application wants to deliver time critical data in a\nparticular slot. How can it find out a) what the time slots are and\nb) when the next slot is scheduled? With this Qdisc, it cannot do\nthis, AFAICT. The admin might delete the file after configuring the\nQdisc!\n\nUsing the SO_TXTIME option, the application has total control over the\nscheduling. The great advantages of this approach is that we can\nsupport any possible combination of periodic or aperiodic scheduling\nand we can support any priority scheme user space dreams up.\n\nFor example, one can imaging running two or more loops that only\noccasionally collide. When they do collide, which packet should be\nsent first? Just let user space decide.\n\nThanks,\nRichard","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.133; helo=hemlock.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"eYOwl61O\"; dkim-atps=neutral"],"Received":["from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwdlQ0FRfz9s3w\n\tfor ;\n\tMon, 18 Sep 2017 18:02:25 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id D3C4E89C5C;\n\tMon, 18 Sep 2017 08:02:23 +0000 (UTC)","from hemlock.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id 16FPze+pd0wy; Mon, 18 Sep 2017 08:02:22 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id DDA4E84ADE;\n\tMon, 18 Sep 2017 08:02:22 +0000 (UTC)","from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\tby ash.osuosl.org (Postfix) with ESMTP id 599401CEB72\n\tfor ;\n\tMon, 18 Sep 2017 08:02:21 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id 4DA0384ADE\n\tfor ;\n\tMon, 18 Sep 2017 08:02:21 +0000 (UTC)","from hemlock.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id ZFzRmzWjZ-sp for ;\n\tMon, 18 Sep 2017 08:02:20 +0000 (UTC)","from mail-wr0-f177.google.com (mail-wr0-f177.google.com\n\t[209.85.128.177])\n\tby hemlock.osuosl.org (Postfix) with ESMTPS id 9113082E02\n\tfor ;\n\tMon, 18 Sep 2017 08:02:20 +0000 (UTC)","by mail-wr0-f177.google.com with SMTP id 108so5493454wra.5\n\tfor ;\n\tMon, 18 Sep 2017 01:02:20 -0700 (PDT)","from localhost (213-225-5-51.nat.highway.a1.net. [213.225.5.51])\n\tby smtp.gmail.com with ESMTPSA id\n\th29sm6518742wrf.76.2017.09.18.01.02.16\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tMon, 18 Sep 2017 01:02:17 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=XpO0+j0RKYuqbZKQfD2hSJMbeKGDn8pEJKLvmdTebBo=;\n\tb=eYOwl61Oq5etvFmEzJvJU5Hqn9zq264V2ylu2TkwHeUrHDkwMuwr08t62n2olDfXcq\n\t18kydVaE6pOgnKgbLxqgn4uenk0mh57u51A7DZjfmwYBLJ0ml8w3RLc0/cy5xWJfuUO0\n\tE60xp3OKIkKUc4cBnWqzDUuzER5M3y9xC0FbRY0KDg8/69f7PCLdmeMSJB4P/vZRUwXd\n\tdc1ms2AfKsLFakSLLlAgwsuleQSwdI+V56pR+cMFv0qCPormCHSvjkKb5yJsWYZ8ms8n\n\tT7nsPMf8uFIaTYZjYy9RhlZFYCEGoSsam/IxTZAKxEjL4RhA1DA2eMMyxzNPr9RPkNwo\n\tJwEA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=XpO0+j0RKYuqbZKQfD2hSJMbeKGDn8pEJKLvmdTebBo=;\n\tb=nBxZLJ7XxBEaUEOKeKXe69JaLa6yw9tjWixIaW3tHwRqjkBWWIY3oNUba0aJ0TrMX3\n\tdmP3Nj2KPQ3ZkEt7q2PBz4unSVJK21gGd41iOGRDoE84esftkVkHLvLeBUclsoBohTQD\n\tvN8/8vXoDrgVpXXbVwZe0RIs3U9RdveJuxh2EE+S0oLWrdmp7H9lTMyyOl7rU6ji5Jp5\n\tyAhFyWCLBEjiUrbTDUqygAfBqwvVCJM0++ueV9cjZfP8k1GbnOMS7zk2chdkc1/wYF9k\n\tYcCT3DJMcsGfUQwzu0PC0ifBNe2KECpLWhQ0NALrgUtuY4DnYT2/QFUqY7m5Y3b9zKdc\n\tcdJQ==","X-Gm-Message-State":"AHPjjUgUccBKMd7bjH+ueWUE76Za6PToiZeW3Zfy9JWSjhxuYwKe4a/T\n\totfkDVxtobneUA==","X-Google-Smtp-Source":"ADKCNb4m06R7/51shmanhk16gDUVFMhmgbmV7IWomURQFvXkyXZNGnComeN0uq3svM/4zkbpaTTjow==","X-Received":"by 10.223.197.72 with SMTP id s8mr29713152wrf.120.1505721738956; \n\tMon, 18 Sep 2017 01:02:18 -0700 (PDT)","Date":"Mon, 18 Sep 2017 10:02:14 +0200","From":"Richard Cochran ","To":"Vinicius Costa Gomes ","Message-ID":"<20170918080214.yrejz67wwnp2pjzf@localhost>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20170901012625.14838-1-vinicius.gomes@intel.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, \n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com,\n\tjesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1769956,"web_url":"http://patchwork.ozlabs.org/comment/1769956/","msgid":"<20170918081248.txhars53icbqsvld@localhost>","list_archive_url":null,"date":"2017-09-18T08:12:48","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":4009,"url":"http://patchwork.ozlabs.org/api/people/4009/","name":"Richard Cochran","email":"richardcochran@gmail.com"},"content":"On Thu, Aug 31, 2017 at 06:26:20PM -0700, Vinicius Costa Gomes wrote:\n> This patchset is an RFC on a proposal of how the Traffic Control subsystem can\n> be used to offload the configuration of traffic shapers into network devices\n> that provide support for them in HW. Our goal here is to start upstreaming\n> support for features related to the Time-Sensitive Networking (TSN) set of\n> standards into the kernel.\n\nJust for the record, here is my score card showing the current status\nof TSN support in Linux. Comments and corrections are more welcome.\n\nThanks,\nRichard\n\n\n | FEATURE | STANDARD | STATUS |\n |------------------------------------------------+---------------------+------------------------------|\n | Synchronization | 802.1AS-2011 | Implemented in |\n | | | - Linux kernel PHC subsystem |\n | | | - linuxptp (userspace) |\n |------------------------------------------------+---------------------+------------------------------|\n | Forwarding and Queuing Enhancements | 802.1Q-2014 sec. 34 | RFC posted (this thread) |\n | for Time-Sensitive Streams (FQTSS) | | |\n |------------------------------------------------+---------------------+------------------------------|\n | Stream Reservation Protocol (SRP) | 802.1Q-2014 sec. 35 | in Open-AVB [1] |\n |------------------------------------------------+---------------------+------------------------------|\n | Audio Video Transport Protocol (AVTP) | IEEE 1722-2011 | DNE |\n |------------------------------------------------+---------------------+------------------------------|\n | Audio/Video Device Discovery, Enumeration, | IEEE 1722.1-2013 | jdksavdecc-c [2] |\n | Connection Management and Control (AVDECC) | | |\n | AVDECC Connection Management Protocol (ACMP) | | |\n | AVDECC Enumeration and Control Protocol (AECP) | | |\n | MAC Address Acquisition Protocol (MAAP) | | in Open-AVB |\n |------------------------------------------------+---------------------+------------------------------|\n | Frame Preemption | P802.1Qbu | DNE |\n | Scheduled Traffic | P802.1Qbv | RFC posted (SO_TXTIME) |\n | SRP Enhancements and Performance Improvements | P802.1Qcc | DNE |\n\n DNE = Does Not Exist (to my knowledge)\n\n1. https://github.com/Avnu/OpenAvnu\n\n (DISCLAIMER from the website:)\n\n It is planned to eventually include the various packet encapsulation types,\n protocol discovery daemons, libraries to convert media clocks to AVB clocks\n and vice versa, and drivers.\n\n This repository does not include all components required to build a full\n production AVB/TSN system (e.g. a turnkey solution to stream stored or live audio\n or video content). Some simple example applications are provided which\n illustrate the flow - but a professional Audio/Video system requires a full media stack\n - including audio and video inputs and outputs, media processing elements, and\n various graphical user interfaces. Various companies provide such integrated\n solutions.\n\n2. https://github.com/jdkoftinoff/jdksavdecc-c","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"EGFeTvVt\"; dkim-atps=neutral"],"Received":["from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwdzf1Jfwz9s7c\n\tfor ;\n\tMon, 18 Sep 2017 18:13:01 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 7344788F06;\n\tMon, 18 Sep 2017 08:13:00 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id v-6lqLcl58-U; Mon, 18 Sep 2017 08:12:59 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id A509888EF7;\n\tMon, 18 Sep 2017 08:12:59 +0000 (UTC)","from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\tby ash.osuosl.org (Postfix) with ESMTP id 0C6651C13E4\n\tfor ;\n\tMon, 18 Sep 2017 08:12:58 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 058F788EF7\n\tfor ;\n\tMon, 18 Sep 2017 08:12:58 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id KUNbbDEnUCl7 for ;\n\tMon, 18 Sep 2017 08:12:56 +0000 (UTC)","from mail-wr0-f194.google.com (mail-wr0-f194.google.com\n\t[209.85.128.194])\n\tby whitealder.osuosl.org (Postfix) with ESMTPS id A5C7187F7F\n\tfor ;\n\tMon, 18 Sep 2017 08:12:56 +0000 (UTC)","by mail-wr0-f194.google.com with SMTP id p37so4585676wrb.5\n\tfor ;\n\tMon, 18 Sep 2017 01:12:56 -0700 (PDT)","from localhost (213-225-5-51.nat.highway.a1.net. [213.225.5.51])\n\tby smtp.gmail.com with ESMTPSA id\n\tv2sm5690527wmf.8.2017.09.18.01.12.53\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tMon, 18 Sep 2017 01:12:54 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=RL0Ud2azyd4xHFmmpy05C4OTlEROt4+Om6FrMvmf31A=;\n\tb=EGFeTvVt4IGM0wMz4agluDwkKKG9dpLCfzRQqI/YfGz8rIGseNJhDJj+gJOECjiSS0\n\tnhLC9bB5UnPFlvasJYxqt6y0l8bUmj7DqMjMtqJSFqlMvLZHIKOMj0fqgafn2+X1bR71\n\tW3c7fKzlQtLpip8+5e3Qy/kbUkZ/GbJg+Wob9mtZZYvY/VbWZDoBfSr+7GoD0Q7KAxhk\n\t2MsDj5X2ZPX3sYt5+0pQhjmwHnyRjIWRLgfT+pfZ+hS0yYGzUNR9ojhoi4DVQ2fPhks4\n\tpz+iL7RiDnzqx87aMOf+VGFJht660mW5GhC5NW2Zwu0BiikMNvHjbi+onQ8anvew/5TY\n\tf52Q==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=RL0Ud2azyd4xHFmmpy05C4OTlEROt4+Om6FrMvmf31A=;\n\tb=J54h/BbHB79RlB8DtmdAikg0zkxlgQVWkMKzA1cNlRYF+Tp/Vfh6it9GnZw99diUF0\n\tSMYZbaSJvHOtIMoZSUab2OEStu/yOBMm2bi+roNmprTowmXppZ6deGuzvmCXozLAgHKp\n\t4itpwlqijV9pAAzl5DkxqZF9m0kY0AG7bgCoyXPonK6E690tmdwSUxgMACYlI90f5x3v\n\t6xAYkAOjbN4of0rJxIYUs2xMwZzxgLlJzXFpbf9/K0yzrUMjUdZaCiwaE8QgPGb+qIb+\n\tMnyALN2E6iRqlccJtc5VOG+juaLxzZtihURbGBUmFd6HdpCa9wsMPHFeZpMo/M40g9EC\n\t3cAg==","X-Gm-Message-State":"AHPjjUiSGwz22bZ8kpHj2kGiV4uoVo0m0Kc7nR39OJzf06Ql3xlfE8+/\n\tKdTvpr86hvaTPQ==","X-Google-Smtp-Source":"ADKCNb7Oz5qzWhTxuIN1bZMpPeeqneCRs81P1voNLybWabMAqezvW9/ca3cn/6XOpRvXbpwoS1k4MQ==","X-Received":"by 10.223.142.73 with SMTP id n67mr25657117wrb.278.1505722375075;\n\tMon, 18 Sep 2017 01:12:55 -0700 (PDT)","Date":"Mon, 18 Sep 2017 10:12:48 +0200","From":"Richard Cochran ","To":"Vinicius Costa Gomes ","Message-ID":"<20170918081248.txhars53icbqsvld@localhost>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20170901012625.14838-1-vinicius.gomes@intel.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, henrik@austad.us, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, boon.leong.ong@intel.com,\n\txiyou.wangcong@gmail.com, tglx@linutronix.de,\n\tjesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1770099,"web_url":"http://patchwork.ozlabs.org/comment/1770099/","msgid":"<20170918114652.GA13349@sisyphus.home.austad.us>","list_archive_url":null,"date":"2017-09-18T11:46:52","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":67212,"url":"http://patchwork.ozlabs.org/api/people/67212/","name":"Henrik Austad","email":"henrik@austad.us"},"content":"On Mon, Sep 18, 2017 at 10:02:14AM +0200, Richard Cochran wrote:\n> On Thu, Aug 31, 2017 at 06:26:20PM -0700, Vinicius Costa Gomes wrote:\n> > * Time-aware shaper (802.1Qbv):\n> \n> I just posted a working alternative showing how to handle 802.1Qbv and\n> many other Ethernet field buses.\n\nYes, I saw them, grabbing them for testing now - thanks!\n\n> > The idea we are currently exploring is to add a \"time-aware\", priority based\n> > qdisc, that also exposes the Tx queues available and provides a mechanism for\n> > mapping priority <-> traffic class <-> Tx queues in a similar fashion as\n> > mqprio. We are calling this qdisc 'taprio', and its 'tc' cmd line would be:\n> > \n> > $ $ tc qdisc add dev ens4 parent root handle 100 taprio num_tc 4 \\\n> > \t map 2 2 1 0 3 3 3 3 3 3 3 3 3 3 3 3 \\\n> > \t queues 0 1 2 3 \\\n> > \t sched-file gates.sched [base-time ] \\\n> > [cycle-time ] [extension-time ]\n> > \n> > is multi-line, with each line being of the following format:\n> > \n> > \n> > Qbv only defines one : \"S\" for 'SetGates'\n> > \n> > For example:\n> > \n> > S 0x01 300\n> > S 0x03 500\n> > \n> > This means that there are two intervals, the first will have the gate\n> > for traffic class 0 open for 300 nanoseconds, the second will have\n> > both traffic classes open for 500 nanoseconds.\n> \n> The idea of the schedule file will not work in practice. Consider the\n> fact that the application wants to deliver time critical data in a\n> particular slot. How can it find out a) what the time slots are and\n> b) when the next slot is scheduled? With this Qdisc, it cannot do\n> this, AFAICT. The admin might delete the file after configuring the\n> Qdisc!\n> \n> Using the SO_TXTIME option, the application has total control over the\n> scheduling. The great advantages of this approach is that we can\n> support any possible combination of periodic or aperiodic scheduling\n> and we can support any priority scheme user space dreams up.\n\nUsing SO_TXTIME makes a lot of sense. TSN has a presentation_time, which \nyou can use to deduce the time it should be transmitted (Class A has a 2ms \nlatency guarantee, B has 50), but given how TSN uses the timestamp, it will \nwrap every 4.3 seconds, using SO_TXTIME allows you to schedule transmission \nat a much later time. It should also lessen the dependency on a specific \nprotocol, which is also good.\n\n> For example, one can imaging running two or more loops that only\n> occasionally collide. When they do collide, which packet should be\n> sent first? Just let user space decide.\n\nIf 2 userspace apps send to the same Tx-queue with the same priority, would \nit not make sense to just do FIFO? For all practical purposes, they have \nthe same importance (same SO_PRIORITY, same SO_TXTIME). If the priority \ndiffers, then they would be directed to different queues, where one queue \nwill take presedence anyway.\n\nHow far into the future would it make sense to schedule packets anyway?\n\nI'll have a look at the other series you just posted!","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.137; helo=fraxinus.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=austad-us.20150623.gappssmtp.com\n\theader.i=@austad-us.20150623.gappssmtp.com\n\theader.b=\"B2Qany/6\"; dkim-atps=neutral"],"Received":["from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwkky1mZYz9rxj\n\tfor ;\n\tMon, 18 Sep 2017 21:47:20 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id BF121874B7;\n\tMon, 18 Sep 2017 11:47:18 +0000 (UTC)","from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id TPKmWWWXS66L; Mon, 18 Sep 2017 11:47:16 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id C28BE874B2;\n\tMon, 18 Sep 2017 11:47:16 +0000 (UTC)","from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\tby ash.osuosl.org (Postfix) with ESMTP id E3BA31C42BA\n\tfor ;\n\tMon, 18 Sep 2017 11:47:14 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id D3131874B2\n\tfor ;\n\tMon, 18 Sep 2017 11:47:14 +0000 (UTC)","from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id rPYJI8_BYkOY for ;\n\tMon, 18 Sep 2017 11:47:13 +0000 (UTC)","from mail-lf0-f42.google.com (mail-lf0-f42.google.com\n\t[209.85.215.42])\n\tby fraxinus.osuosl.org (Postfix) with ESMTPS id 02FA4874A2\n\tfor ;\n\tMon, 18 Sep 2017 11:47:12 +0000 (UTC)","by mail-lf0-f42.google.com with SMTP id u21so233821lfk.12\n\tfor ;\n\tMon, 18 Sep 2017 04:47:12 -0700 (PDT)","from sisyphus.home.austad.us (162.51-175-50.customer.lyse.net.\n\t[51.175.50.162]) by smtp.gmail.com with ESMTPSA id\n\tz26sm1785015lja.59.2017.09.18.04.47.08\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 18 Sep 2017 04:47:09 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=austad-us.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=dAFirSXSZZCA18v6V6r70EdX7ko+QrIvQyw4g3n88Ww=;\n\tb=B2Qany/6oXJAuHcXHVkYynSqOnd1E/H2rJtnB8F2VeVarhR9Q0yRKwIiUbwpox87c8\n\tWuwZtluhqShP8pXCjP16ulXje3nLqP5DfwMsyparPOT6Y7bI6JI0DCUL/qhhRvP3r0bf\n\t0GtT7ajhdf5N+YqiplTdc6ecSpWlrLUaqr6ajby1sCuhBkCrsZ7xXuxgtJofJS2uUkMD\n\tMG/53bL210sid5t5Vd5H4kcRXR4b52hx+DGhV8x1sqqISU1Ffx5et6HSSLFQhD/sewnU\n\tYZ0FuLckF6BkrCaL1Wll7nl0Aox9iv6MjiSx8coOCM4dh6kyNi29At1G3xtWefQMySix\n\tDxXg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=dAFirSXSZZCA18v6V6r70EdX7ko+QrIvQyw4g3n88Ww=;\n\tb=Qv4ELrLwRo/kQcO9Ic5qosrEsLFkIAcjAxEOaIfPq5zzGEeBmLbcUh6dKvZV07u56C\n\twcbB8scchXnl0t3PoahW4AVJyaOU362w1bS9f5Qzv7325yifDAMXAaReLSpdyJefn1uH\n\teLsJteOtcvJBrGdR4tbK4c4uFRX3ewffsrLLR23uy+NgCoDo1upuVbcr3Y4jmwMxKJ0t\n\tR1HKeLobmW8uyZfQayAjUM3CfvXbE5D4tk2FSINRh5wtkLfk3NQz03xEL95ozEk3MO/Z\n\tKLXAo0b1+7GwkZi+tVDXnChChY3qJLIYRhYyLxr/aKosuo1OzJ7m+ycdyMYFlTRgxPYK\n\tpoHw==","X-Gm-Message-State":"AHPjjUjRk9vIL3S9H05N79sb2l32I45x5uGs8/HiAg5H8EVPIey0TB6s\n\t23DUhrlhmg1IJNQt","X-Google-Smtp-Source":"ADKCNb4ir5ylGZozDjkhjdjpLXcN2bsvzF6bQRA3zJxA+rs1b72y8TKtbBCCVCmJxal8owVuJ0MKaA==","X-Received":"by 10.46.7.10 with SMTP id 10mr10356189ljh.153.1505735230368;\n\tMon, 18 Sep 2017 04:47:10 -0700 (PDT)","Date":"Mon, 18 Sep 2017 13:46:52 +0200","From":"Henrik Austad ","To":"Richard Cochran ","Message-ID":"<20170918114652.GA13349@sisyphus.home.austad.us>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170918080214.yrejz67wwnp2pjzf@localhost>","MIME-Version":"1.0","In-Reply-To":"<20170918080214.yrejz67wwnp2pjzf@localhost>","User-Agent":"Mutt/1.5.24 (2015-08-30)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, \n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com,\n\tjesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"multipart/mixed;\n\tboundary=\"===============6154326797316196072==\"","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1770573,"web_url":"http://patchwork.ozlabs.org/comment/1770573/","msgid":"<87k20vip3f.fsf@intel.com>","list_archive_url":null,"date":"2017-09-18T23:06:28","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":72272,"url":"http://patchwork.ozlabs.org/api/people/72272/","name":"Vinicius Costa Gomes","email":"vinicius.gomes@intel.com"},"content":"Hi Richard,\n\nRichard Cochran writes:\n\n> On Thu, Aug 31, 2017 at 06:26:20PM -0700, Vinicius Costa Gomes wrote:\n>> * Time-aware shaper (802.1Qbv):\n>\n> I just posted a working alternative showing how to handle 802.1Qbv and\n> many other Ethernet field buses.\n>\n>> The idea we are currently exploring is to add a \"time-aware\", priority based\n>> qdisc, that also exposes the Tx queues available and provides a mechanism for\n>> mapping priority <-> traffic class <-> Tx queues in a similar fashion as\n>> mqprio. We are calling this qdisc 'taprio', and its 'tc' cmd line would be:\n>>\n>> $ $ tc qdisc add dev ens4 parent root handle 100 taprio num_tc 4 \\\n>> \t map 2 2 1 0 3 3 3 3 3 3 3 3 3 3 3 3 \\\n>> \t queues 0 1 2 3 \\\n>> \t sched-file gates.sched [base-time ] \\\n>> [cycle-time ] [extension-time ]\n>>\n>> is multi-line, with each line being of the following format:\n>> \n>>\n>> Qbv only defines one : \"S\" for 'SetGates'\n>>\n>> For example:\n>>\n>> S 0x01 300\n>> S 0x03 500\n>>\n>> This means that there are two intervals, the first will have the gate\n>> for traffic class 0 open for 300 nanoseconds, the second will have\n>> both traffic classes open for 500 nanoseconds.\n>\n> The idea of the schedule file will not work in practice. Consider the\n> fact that the application wants to deliver time critical data in a\n> particular slot. How can it find out a) what the time slots are and\n> b) when the next slot is scheduled? With this Qdisc, it cannot do\n> this, AFAICT. The admin might delete the file after configuring the\n> Qdisc!\n\nThat's the point, the application does not need to know that, and asking\nthat would be stupid. From the point of view of the Qbv specification,\napplications only need to care about its basic bandwidth requirements:\nits interval, frame size, frames per interval (using the terms of the\nSRP section of 802.1Q). The traffic schedule is provided (off band) by a\n\"god box\" which knows all the requirements of all applications in all\nthe nodes and how they are connected.\n\n(And that's another nice point of how 802.1Qbv works, applications do\nnot need to be changed to use it, and I think we should work to achieve\nthis on the Linux side)\n\nThat being said, that only works for kinds of traffic that maps well to\nthis configuration in advance model, which is the model that the IEEE\n(see 802.1Qcc) and the AVNU Alliance[1] are pushing for.\n\nIn the real world, I can see multiple types of applications, some using\nsomething like TXTIME, and some configured in advance.\n\n>\n> Using the SO_TXTIME option, the application has total control over the\n> scheduling. The great advantages of this approach is that we can\n> support any possible combination of periodic or aperiodic scheduling\n> and we can support any priority scheme user space dreams up.\n\nIt has the disavantage of that the scheduling information has to be\nin-band with the data. I *really* think that for scheduled traffic,\nthere should be a clear separation, we should not mix the dataflow with\nscheduling. In short, an application in the network don't need to have\nall the information necessary to schedule its own traffic well.\n\nI have two points here: 1. I see both \"solutions\" (taprio and SO_TXTIME)\nas being ortoghonal and useful, both; 2. trying to make one do the job\nof the other, however, looks like \"If all I have is a hammer, everything\nlooks like a nail\".\n\nIn short, I see a per-packet transmission time and a per-queue schedule\nas solutions to different problems.\n\n>\n> For example, one can imaging running two or more loops that only\n> occasionally collide. When they do collide, which packet should be\n> sent first? Just let user space decide.\n>\n> Thanks,\n> Richard\n\nCheers,\n--\nVinicius\n\n[1]\nhttp://avnu.org/theory-of-operation-for-tsn-enabled-industrial-systems/","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.136; helo=silver.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","Received":["from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xx1pk1TG6z9s2G\n\tfor ;\n\tTue, 19 Sep 2017 09:06:37 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id 066BF2DC88;\n\tMon, 18 Sep 2017 23:06:36 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id jh3GuGUVPsi8; Mon, 18 Sep 2017 23:06:35 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby silver.osuosl.org (Postfix) with ESMTP id 487AA30BC5;\n\tMon, 18 Sep 2017 23:06:35 +0000 (UTC)","from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id E7B221C20F0\n\tfor ;\n\tMon, 18 Sep 2017 23:06:33 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id DFDA630BC5\n\tfor ;\n\tMon, 18 Sep 2017 23:06:33 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id NnR3Y529ZSGz for ;\n\tMon, 18 Sep 2017 23:06:32 +0000 (UTC)","from mga11.intel.com (mga11.intel.com [192.55.52.93])\n\tby silver.osuosl.org (Postfix) with ESMTPS id D49352DC88\n\tfor ;\n\tMon, 18 Sep 2017 23:06:32 +0000 (UTC)","from fmsmga006.fm.intel.com ([10.253.24.20])\n\tby fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t18 Sep 2017 16:06:28 -0700","from ellie.jf.intel.com (HELO ellie) ([10.24.13.66])\n\tby fmsmga006.fm.intel.com with ESMTP; 18 Sep 2017 16:06:28 -0700"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,415,1500966000\"; d=\"scan'208\";a=\"153317313\"","From":"Vinicius Costa Gomes ","To":"Richard Cochran ","In-Reply-To":"<20170918080214.yrejz67wwnp2pjzf@localhost>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170918080214.yrejz67wwnp2pjzf@localhost>","User-Agent":"Notmuch/0.21 (http://notmuchmail.org) Emacs/25.1.1\n\t(x86_64-pc-linux-gnu)","Date":"Mon, 18 Sep 2017 16:06:28 -0700","Message-ID":"<87k20vip3f.fsf@intel.com>","MIME-Version":"1.0","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, \n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com,\n\tjesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1770659,"web_url":"http://patchwork.ozlabs.org/comment/1770659/","msgid":"<20170919052244.77umdxuze53t6j22@localhost>","list_archive_url":null,"date":"2017-09-19T05:22:44","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":4009,"url":"http://patchwork.ozlabs.org/api/people/4009/","name":"Richard Cochran","email":"richardcochran@gmail.com"},"content":"On Mon, Sep 18, 2017 at 04:06:28PM -0700, Vinicius Costa Gomes wrote:\n> That's the point, the application does not need to know that, and asking\n> that would be stupid.\n\nOn the contrary, this information is essential to the application.\nProbably you have never seen an actual Ethernet field bus in\noperation? In any case, you are missing the point.\n\n> (And that's another nice point of how 802.1Qbv works, applications do\n> not need to be changed to use it, and I think we should work to achieve\n> this on the Linux side)\n\nOnce you start to care about real time performance, then you need to\nconsider the applications. This is industrial control, not streaming\nyour tunes from your ipod.\n \n> That being said, that only works for kinds of traffic that maps well to\n> this configuration in advance model, which is the model that the IEEE\n> (see 802.1Qcc) and the AVNU Alliance[1] are pushing for.\n\nAgain, you are missing the point of what they aiming for. I have\nlooked at a number of production systems, and in each case the\ndevelopers want total control over the transmission, in order to\nreduce latency to an absolute minimum. Typically the data to be sent\nare available only microseconds before the transmission deadline.\n\nConsider OpenAVB on github that people are already using. Take a look\nat simple_talker.c and explain how \"applications do not need to be\nchanged to use it.\"\n\n> [1]\n> http://avnu.org/theory-of-operation-for-tsn-enabled-industrial-systems/\n\nDid you even read this?\n\n [page 24]\n\n As described in section 2, some industrial control systems require\n predictable, very low latency and cycle-to-cycle variation to meet\n hard real-time application requirements. In these systems,\n multiple distributed controllers commonly synchronize their\n sensor/actuator operations with other controllers by scheduling\n these operations in time, typically using a repeating control\n cycle.\n ...\n The gate control mechanism is itself a time-aware PTP application\n operating within a bridge or end station port.\n\nIt is an application, not a \"god box.\"\n\n> In short, I see a per-packet transmission time and a per-queue schedule\n> as solutions to different problems.\n\nWell, I can agree with that. For some non real-time applications,\nbandwidth shaping is enough, and your Qdisc idea is sufficient. For\nthe really challenging TSN targets (industrial control, automotive),\nyour idea of an opaque schedule file won't fly.\n\nThanks,\nRichard","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.133; helo=hemlock.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"HHxwvmf/\"; dkim-atps=neutral"],"Received":["from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxB8v7150z9s5L\n\tfor ;\n\tTue, 19 Sep 2017 15:22:55 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id B7D0387B52;\n\tTue, 19 Sep 2017 05:22:53 +0000 (UTC)","from hemlock.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id h0FXSBwIx-j6; Tue, 19 Sep 2017 05:22:52 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id AA99E87AE8;\n\tTue, 19 Sep 2017 05:22:52 +0000 (UTC)","from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id 917A71C059B\n\tfor ;\n\tTue, 19 Sep 2017 05:22:51 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id D3B7526C7C\n\tfor ;\n\tTue, 19 Sep 2017 05:22:46 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id PDEyGCHxe6Gi for ;\n\tTue, 19 Sep 2017 05:22:46 +0000 (UTC)","from mail-wr0-f173.google.com (mail-wr0-f173.google.com\n\t[209.85.128.173])\n\tby silver.osuosl.org (Postfix) with ESMTPS id E8DBC26C7A\n\tfor ;\n\tTue, 19 Sep 2017 05:22:45 +0000 (UTC)","by mail-wr0-f173.google.com with SMTP id g29so2030024wrg.11\n\tfor ;\n\tMon, 18 Sep 2017 22:22:50 -0700 (PDT)","from localhost (213-225-0-7.nat.highway.a1.net. [213.225.0.7])\n\tby smtp.gmail.com with ESMTPSA id\n\tv98sm9448210wrc.71.2017.09.18.22.22.46\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tMon, 18 Sep 2017 22:22:47 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=ibSERWtQWU9cBuDM2HX64iuxAp/kL21/e9UgZ4T/ZDo=;\n\tb=HHxwvmf/uedtli/WSHmiinnIRqtB6wlTf42Nd24qEh+pYknuwz1nSb6cizEO7QtY9f\n\tFb8OknJ80+wjcX7MPPxseYUohW+shXeFBwFLOsLjUnBvS39Z8EESHa33EwSjCKRDGma5\n\tnp857dWRnFer0LLepxp+DeIKdPdz2cvS2ksygm803CVDZRUljLOUzUQQMYFq25LiBRnq\n\tVjlsPe3mBi8VhGkDZ0t8gzCoetCRuSu6gtIbRxzqy6Z/35GfM9TZ7wJ2hr9sHdnyhTkT\n\t0YSgyQIlfF2EFOgcZxWMlbYdgVXSW/VSzNnAThDtjj3xFmO9bkv05DNBJbRefRbNHHyM\n\tve0g==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=ibSERWtQWU9cBuDM2HX64iuxAp/kL21/e9UgZ4T/ZDo=;\n\tb=mR/0FcM5FbR5b2nUcDc0WiyL6uvXR5cJ/wKCn4MXk8y0hvA7Prpjyr223t60jSAFap\n\tzmlaMdbS4O1g9LGRWW72qh7SMcZ7A+VEGx8RqIF4PR3XoX8yH0N6xywr7PYuNiIvA7KC\n\tYPstQK5AtilS8fANd6XjCNYB3KRktyPsGI3XaVmw+VSBlre5zyBtMD4zgLjy2sWFZ5xd\n\tsB8a+JttOpyctPmuFk6W9Dtz//MG16Fqpz30Q6bLJt4sJQxeAPdq9ssSHyNCgYy2FCke\n\tSxcoIaB5sRV788VsgHjsbpTl6/LOYweTnxQkc1qoGyaPdmvLkPWFB91yyZJB2LSobxkg\n\tbCmA==","X-Gm-Message-State":"AHPjjUi28GTTubx1zwNrSq0XdnD/XXv+uNPoJxn362/0Bj+fo3QJ6DxG\n\tAe6PdsVMI2jEmGoxvl6VkC4=","X-Google-Smtp-Source":"AOwi7QAXJf/ubIhLrtci52tFYc7Nh9NxhT0PmE2RM6KTa5W0Sub/uZgYYCLoI3uRi1aYu1y20XGu1A==","X-Received":"by 10.223.138.153 with SMTP id y25mr182966wry.59.1505798568856; \n\tMon, 18 Sep 2017 22:22:48 -0700 (PDT)","Date":"Tue, 19 Sep 2017 07:22:44 +0200","From":"Richard Cochran ","To":"Vinicius Costa Gomes ","Message-ID":"<20170919052244.77umdxuze53t6j22@localhost>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170918080214.yrejz67wwnp2pjzf@localhost>\n\t<87k20vip3f.fsf@intel.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<87k20vip3f.fsf@intel.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, \n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com,\n\tjesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1770990,"web_url":"http://patchwork.ozlabs.org/comment/1770990/","msgid":"<20170919131443.GA28667@sisyphus.home.austad.us>","list_archive_url":null,"date":"2017-09-19T13:14:43","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":67212,"url":"http://patchwork.ozlabs.org/api/people/67212/","name":"Henrik Austad","email":"henrik@austad.us"},"content":"Hi all,\n\nOn Tue, Sep 19, 2017 at 07:22:44AM +0200, Richard Cochran wrote:\n> On Mon, Sep 18, 2017 at 04:06:28PM -0700, Vinicius Costa Gomes wrote:\n> > That's the point, the application does not need to know that, and asking\n> > that would be stupid.\n> \n> On the contrary, this information is essential to the application.\n> Probably you have never seen an actual Ethernet field bus in\n> operation? In any case, you are missing the point.\n> \n> > (And that's another nice point of how 802.1Qbv works, applications do\n> > not need to be changed to use it, and I think we should work to achieve\n> > this on the Linux side)\n> \n> Once you start to care about real time performance, then you need to\n> consider the applications. This is industrial control, not streaming\n> your tunes from your ipod.\n\nDo not underestimate the need for media over TSN. I fully see your point of \nreal-time systems, but they are not the only valid use-cases for TSN.\n\n> > That being said, that only works for kinds of traffic that maps well to\n> > this configuration in advance model, which is the model that the IEEE\n> > (see 802.1Qcc) and the AVNU Alliance[1] are pushing for.\n> \n> Again, you are missing the point of what they aiming for. I have\n> looked at a number of production systems, and in each case the\n> developers want total control over the transmission, in order to\n> reduce latency to an absolute minimum. Typically the data to be sent\n> are available only microseconds before the transmission deadline.\n> \n> Consider OpenAVB on github that people are already using. Take a look\n> at simple_talker.c and explain how \"applications do not need to be\n> changed to use it.\"\n\nI do not think simple-talker was everintended to be how users of AVB should \nbe implemented, but as a demonstration of what the protocol could do.\n\nALSA/V4L2 should supply some interface to this so that you can attach \nmedia-applications to it without the application itself having to be \"TSN \naware\".\n\n> > [1]\n> > http://avnu.org/theory-of-operation-for-tsn-enabled-industrial-systems/\n> \n> Did you even read this?\n> \n> [page 24]\n> \n> As described in section 2, some industrial control systems require\n> predictable, very low latency and cycle-to-cycle variation to meet\n> hard real-time application requirements. In these systems,\n> multiple distributed controllers commonly synchronize their\n> sensor/actuator operations with other controllers by scheduling\n> these operations in time, typically using a repeating control\n> cycle.\n> ...\n> The gate control mechanism is itself a time-aware PTP application\n> operating within a bridge or end station port.\n> \n> It is an application, not a \"god box.\"\n>\n> > In short, I see a per-packet transmission time and a per-queue schedule\n> > as solutions to different problems.\n> \n> Well, I can agree with that. For some non real-time applications,\n> bandwidth shaping is enough, and your Qdisc idea is sufficient. For\n> the really challenging TSN targets (industrial control, automotive),\n> your idea of an opaque schedule file won't fly.\n\nWould it make sense to adapt the proposed Qdisc here as well as the \nback-o-the-napkin idea in the other thread to to a per-socket queue for \neach priority and then sort those sockets based on SO_TXTIME?\n\nTSN operates on a per-StreamID basis, and that should map fairly well to a \nper-socket approach I think (let us just assume that an application that \nsends TSN traffic will open up a separate socket for each stream.\n\nThis should allow a userspace application that is _very_ aware of its \ntiming constraints to send frames exactly when it needs to as you have \nSO_TXTIME available. It would also let applications that basically want a \nfine-grained rate control (audio and video comes to mind) to use the same \nqdisc.\n\nFor those sockets that do not support SO_TXTIME, but still map to a \npriority handled by sch_cbs (or whatever it'll end up being called) you can \nset the transmit-time to be the time of the last skb in the queue + an \ndelta which will give you the correct rate (TSN operates on observation \nintervals which you can specify via tc when you create the queues).\n\nThen you can have, as you propose in your other series, a hrtimer that is \nbeing called when the next SO_TXTIME enters, grab a skb and move it to the \nhw-queue. This should also allow you to keep a sorted per-socket queue \nshould an application send frames in the wrong order, without having to \nrearrange descriptors for the DMA machinery.\n\nIf this makes sense, I am more than happy to give it a stab and see how it \ngoes.\n\n-Henrik","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=austad-us.20150623.gappssmtp.com\n\theader.i=@austad-us.20150623.gappssmtp.com\n\theader.b=\"YmyjFhfW\"; dkim-atps=neutral"],"Received":["from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxNds0stnz9sBZ\n\tfor ;\n\tTue, 19 Sep 2017 23:15:11 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id C7CBB886B6;\n\tTue, 19 Sep 2017 13:15:09 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id ZdX3XG+v34cV; Tue, 19 Sep 2017 13:15:07 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id A6EA18870B;\n\tTue, 19 Sep 2017 13:15:07 +0000 (UTC)","from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\tby ash.osuosl.org (Postfix) with ESMTP id DE74D1BFF07\n\tfor ;\n\tTue, 19 Sep 2017 13:15:05 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id D49E3878CA\n\tfor ;\n\tTue, 19 Sep 2017 13:15:05 +0000 (UTC)","from hemlock.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id rzUGdiThUfbk for ;\n\tTue, 19 Sep 2017 13:15:03 +0000 (UTC)","from mail-lf0-f51.google.com (mail-lf0-f51.google.com\n\t[209.85.215.51])\n\tby hemlock.osuosl.org (Postfix) with ESMTPS id B425A878C9\n\tfor ;\n\tTue, 19 Sep 2017 13:15:03 +0000 (UTC)","by mail-lf0-f51.google.com with SMTP id y187so3655920lfc.8\n\tfor ;\n\tTue, 19 Sep 2017 06:15:03 -0700 (PDT)","from sisyphus.home.austad.us (162.51-175-50.customer.lyse.net.\n\t[51.175.50.162]) by smtp.gmail.com with ESMTPSA id\n\th29sm2392183ljf.36.2017.09.19.06.14.59\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 19 Sep 2017 06:14:59 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=austad-us.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=nKGIU2G6UXvTDBDnczNNIKWyDZiGiw0IkPtAjng+lyQ=;\n\tb=YmyjFhfWP1mV93c5BLB2rNB3u/zPB/1Iuaq5qFy2dpXJeyg2xOFn38HR0usX5crGav\n\t3E5zgygbi4Ow6bOxY/tMN5S95JKp35swwgAdmvDrlNbQqjKMigy0nQ5iXJnMfCskzZqS\n\tVnJfZebF41obmcOsiKImccWtnOx1xvWz5j/Z/XwHC9/o4fPLqQDDLX2p2LjBP2U/f4lW\n\thE76mOoB+WBNlJRTNqn6a7iSpg8S+l8BW0ZhucA/xpSTIslRuR72Bit8gB3OHqN+rCqu\n\tRQeLUKnJVhPyQXewk+1iOUyDDmUbMu7SdGEhs8MtTlHaP6iiPpHYKhDNntoOw6akW8Nz\n\tIBEQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=nKGIU2G6UXvTDBDnczNNIKWyDZiGiw0IkPtAjng+lyQ=;\n\tb=WmCndBa7QBawXGaLHjhY86imTn0GwK4QUM2OzOH/an1yNuRyzzTFDqCp0t51yloQKp\n\t5vTx3adGc7TpBasGcx/Vgg7pcUR+CrPeNEEgZHTHB+Io/XD1N8zdT2Ue3JYuIW9qaTLA\n\tSabuUbPOyF6CZJ5GG7RNYrODl4QKOfH+r9tXDFw0ArisQhbDdoK/8jXGgMRhWbk7vF+T\n\tsvXpjhgj5l5dxQ+8kE5jlcV/O7qd/JYpVnYuU13ywVitSI0wjDGOflGJQOWV8yI+Ho5O\n\tyne1CR4+SVsK7qUE0hPpn3Dtrgq89UCX0u4v7FeX08iLOYKBAqUJ+yYXIuSlapaRZ7PH\n\tHS0A==","X-Gm-Message-State":"AHPjjUgG4BZKM9QVvBn0zeJYL9p9atGZYkRlVxtQUfNDlVPCHSmGdrBx\n\tlvZEGR7Q3BEG7VMoo9hyKz8PJw==","X-Google-Smtp-Source":"AOwi7QCBK9hkdY2/pfSgS6P+D2EVlk9DuPjUEQAH9YPts7XVDg8rjfC+RmG/eDO9WrzgONmBhr6Plw==","X-Received":"by 10.25.125.197 with SMTP id y188mr603708lfc.61.1505826901349; \n\tTue, 19 Sep 2017 06:15:01 -0700 (PDT)","Date":"Tue, 19 Sep 2017 15:14:43 +0200","From":"Henrik Austad ","To":"Richard Cochran ","Message-ID":"<20170919131443.GA28667@sisyphus.home.austad.us>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170918080214.yrejz67wwnp2pjzf@localhost>\n\t<87k20vip3f.fsf@intel.com>\n\t<20170919052244.77umdxuze53t6j22@localhost>","MIME-Version":"1.0","In-Reply-To":"<20170919052244.77umdxuze53t6j22@localhost>","User-Agent":"Mutt/1.5.24 (2015-08-30)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, \n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com,\n\tjesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"multipart/mixed;\n\tboundary=\"===============7329968058398296113==\"","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1771475,"web_url":"http://patchwork.ozlabs.org/comment/1771475/","msgid":"<87wp4ufchl.fsf@intel.com>","list_archive_url":null,"date":"2017-09-20T00:19:18","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":72272,"url":"http://patchwork.ozlabs.org/api/people/72272/","name":"Vinicius Costa Gomes","email":"vinicius.gomes@intel.com"},"content":"Hi Richard,\n\nRichard Cochran writes:\n\n> On Mon, Sep 18, 2017 at 04:06:28PM -0700, Vinicius Costa Gomes wrote:\n>> That's the point, the application does not need to know that, and asking\n>> that would be stupid.\n>\n> On the contrary, this information is essential to the application.\n> Probably you have never seen an actual Ethernet field bus in\n> operation? In any case, you are missing the point.\n>\n>> (And that's another nice point of how 802.1Qbv works, applications do\n>> not need to be changed to use it, and I think we should work to achieve\n>> this on the Linux side)\n>\n> Once you start to care about real time performance, then you need to\n> consider the applications. This is industrial control, not streaming\n> your tunes from your ipod.\n>\n>> That being said, that only works for kinds of traffic that maps well to\n>> this configuration in advance model, which is the model that the IEEE\n>> (see 802.1Qcc) and the AVNU Alliance[1] are pushing for.\n>\n> Again, you are missing the point of what they aiming for. I have\n> looked at a number of production systems, and in each case the\n> developers want total control over the transmission, in order to\n> reduce latency to an absolute minimum. Typically the data to be sent\n> are available only microseconds before the transmission deadline.\n>\n> Consider OpenAVB on github that people are already using. Take a look\n> at simple_talker.c and explain how \"applications do not need to be\n> changed to use it.\"\n\nJust let me use the mention of OpenAVNU as a hook to explain what we\n(the team I am part of) are working to do, perhaps it will make our\nchoices and designs clearer.\n\nOne of the problems with OpenAVNU is that it's too coupled with the i210\nNIC. One of the things we want is to decouple OpenAVNU from the\ncontroller. The way we thought best was to propose interfaces (that\nwould work along side to the Linux networking stack) as close as\npossible to what the current standards define, that means the IEEE\n802.1Q family of specifications, in the hope that network controller\nvendors would also look at the specifications when designing their\ncontrollers.\n\nOur objective with the Qdiscs we are proposing (both cbs and taprio) is\nto provide a sane way to configure controllers that support TSN features\n(we were looking specifically at the IEEE specs).\n\nAfter we have some rough consensus on the interfaces to use, then we can\nstart working on OpenAVNU.\n\n>\n>> [1]\n>> http://avnu.org/theory-of-operation-for-tsn-enabled-industrial-systems/\n>\n> Did you even read this?\n>\n> [page 24]\n>\n> As described in section 2, some industrial control systems require\n> predictable, very low latency and cycle-to-cycle variation to meet\n> hard real-time application requirements. In these systems,\n> multiple distributed controllers commonly synchronize their\n> sensor/actuator operations with other controllers by scheduling\n> these operations in time, typically using a repeating control\n> cycle.\n> ...\n> The gate control mechanism is itself a time-aware PTP application\n> operating within a bridge or end station port.\n>\n> It is an application, not a \"god box.\"\n>\n>> In short, I see a per-packet transmission time and a per-queue schedule\n>> as solutions to different problems.\n>\n> Well, I can agree with that. For some non real-time applications,\n> bandwidth shaping is enough, and your Qdisc idea is sufficient. For\n> the really challenging TSN targets (industrial control, automotive),\n> your idea of an opaque schedule file won't fly.\n\n(Sorry if I am being annoying here, but the idea of an opaque schedule\nis not ours, that comes from the people who wrote the Qbv specification)\n\nI have a question, what about a controller that doesn't provide a way to\nset a per-packet transmission time, but it supports Qbv/Qbu. What would\nbe your proposal to configure it?\n\n(I think LaunchTime is something specific to the i210, right?)\n\n\nCheers,\n--\nVinicius","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.137; helo=fraxinus.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","Received":["from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxgNZ4n3Kz9s2G\n\tfor ;\n\tWed, 20 Sep 2017 10:19:41 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id DCBF087128;\n\tWed, 20 Sep 2017 00:19:38 +0000 (UTC)","from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id iPNH8SZlXge0; Wed, 20 Sep 2017 00:19:38 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 5AE5D870EB;\n\tWed, 20 Sep 2017 00:19:38 +0000 (UTC)","from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\tby ash.osuosl.org (Postfix) with ESMTP id 0B0911C2272\n\tfor ;\n\tWed, 20 Sep 2017 00:19:37 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 01EF6870EB\n\tfor ;\n\tWed, 20 Sep 2017 00:19:37 +0000 (UTC)","from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id IwmN1A81ZhkA for ;\n\tWed, 20 Sep 2017 00:19:35 +0000 (UTC)","from mga02.intel.com (mga02.intel.com [134.134.136.20])\n\tby fraxinus.osuosl.org (Postfix) with ESMTPS id D63CF870CD\n\tfor ;\n\tWed, 20 Sep 2017 00:19:35 +0000 (UTC)","from fmsmga006.fm.intel.com ([10.253.24.20])\n\tby orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t19 Sep 2017 17:19:19 -0700","from ellie.jf.intel.com (HELO ellie) ([10.24.15.29])\n\tby fmsmga006.fm.intel.com with ESMTP; 19 Sep 2017 17:19:19 -0700"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,419,1500966000\"; d=\"scan'208\";a=\"153831700\"","From":"Vinicius Costa Gomes ","To":"Richard Cochran ","In-Reply-To":"<20170919052244.77umdxuze53t6j22@localhost>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170918080214.yrejz67wwnp2pjzf@localhost>\n\t<87k20vip3f.fsf@intel.com>\n\t<20170919052244.77umdxuze53t6j22@localhost>","User-Agent":"Notmuch/0.21 (http://notmuchmail.org) Emacs/25.1.1\n\t(x86_64-pc-linux-gnu)","Date":"Tue, 19 Sep 2017 17:19:18 -0700","Message-ID":"<87wp4ufchl.fsf@intel.com>","MIME-Version":"1.0","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, \n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com,\n\tjesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1771532,"web_url":"http://patchwork.ozlabs.org/comment/1771532/","msgid":"<20170920015911.18999-1-levipearson@gmail.com>","list_archive_url":null,"date":"2017-09-20T01:59:11","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":72396,"url":"http://patchwork.ozlabs.org/api/people/72396/","name":"Levi Pearson","email":"levipearson@gmail.com"},"content":"On Thu, Aug 31, 2017 at 06:26:20PM -0700, Vinicius Costa Gomes wrote:\n> Hi,\n> \n> This patchset is an RFC on a proposal of how the Traffic Control subsystem can\n> be used to offload the configuration of traffic shapers into network devices\n> that provide support for them in HW. Our goal here is to start upstreaming\n> support for features related to the Time-Sensitive Networking (TSN) set of\n> standards into the kernel.\n\nI'm very excited to see these features moving into the kernel! I am one of the\nmaintainers of the OpenAvnu project and I've been involved in building AVB/TSN\nsystems and working on the standards for around 10 years, so the support that's\nbeen slowly making it into more silicon and now Linux drivers is very\nencouraging.\n\nMy team at Harman is working on endpoint code based on what's in the OpenAvnu\nproject and a few Linux-based platforms. The Qav interface you've proposed will\nfit nicely with our traffic shaper management daemon, which already uses mqprio\nas a base but uses the htb shaper to approximate the Qav credit-based shaper on\nplatforms where launch time scheduling isn't available.\n\nI've applied your patches and plan on testing them in conjunction with our\nshaper manager to see if we run into any hitches, but I don't expect any\nproblems.\n\n> As part of this work, we've assessed previous public discussions related to TSN\n> enabling: patches from Henrik Austad (Cisco), the presentation from Eric Mann\n> at Linux Plumbers 2012, patches from Gangfeng Huang (National Instruments) and\n> the current state of the OpenAVNU project (https://github.com/AVnu/OpenAvnu/).\n> \n> Please note that the patches provided as part of this RFC are implementing what\n> is needed only for 802.1Qav (FQTSS) only, but we'd like to take advantage of\n> this discussion and share our WIP ideas for the 802.1Qbv and 802.1Qbu interfaces\n> as well. The current patches are only providing support for HW offload of the\n> configs.\n> \n> \n> Overview\n> ========\n> \n> Time-sensitive Networking (TSN) is a set of standards that aim to address\n> resources availability for providing bandwidth reservation and bounded latency\n> on Ethernet based LANs. The proposal described here aims to cover mainly what is\n> needed to enable the following standards: 802.1Qat, 802.1Qav, 802.1Qbv and\n> 802.1Qbu.\n> \n> The initial target of this work is the Intel i210 NIC, but other controllers'\n> datasheet were also taken into account, like the Renesas RZ/A1H RZ/A1M group and\n> the Synopsis DesignWare Ethernet QoS controller.\n\nRecent SoCs from NXP (the i.MX 6 SoloX, and all the i.MX 7 and 8 parts) support\nQav shaping as well as scheduled launch functionality; these are the parts I \nhave been mostly working with. Marvell silicon (some subset of Armada processors\nand Link Street DSA switches) generally supports traffic shaping as well.\n\nI think a lack of an interface like this has probably slowed upstream driver\nsupport for this functionality where it exists; most vendors have an out-of-\ntree version of their driver with TSN functionality enabled via non-standard\ninterfaces. Hopefully making it available will encourage vendors to upstream\ntheir driver support!\n\n> Proposal\n> ========\n> \n> Feature-wise, what is covered here are configuration interfaces for HW\n> implementations of the Credit-Based shaper (CBS, 802.1Qav), Time-Aware shaper\n> (802.1Qbv) and Frame Preemption (802.1Qbu). CBS is a per-queue shaper, while\n> Qbv and Qbu must be configured per port, with the configuration covering all\n> queues. Given that these features are related to traffic shaping, and that the\n> traffic control subsystem already provides a queueing discipline that offloads\n> config into the device driver (i.e. mqprio), designing new qdiscs for the\n> specific purpose of offloading the config for each shaper seemed like a good\n> fit.\n\nThis makes sense to me too. The 802.1Q standards are all based on the sort of\nmappings between priority, traffic class, and hardware queues that the existing\ntc infrastructure seems to be modeling. I believe the mqprio module's mapping\nscheme is flexible enough to meet any TSN needs in conjunction with the other\nparts of the kernel qdisc system.\n\n> For steering traffic into the correct queues, we use the socket option\n> SO_PRIORITY and then a mechanism to map priority to traffic classes / Txqueues.\n> The qdisc mqprio is currently used in our tests.\n> \n> As for the shapers config interface:\n> \n> * CBS (802.1Qav)\n> \n> This patchset is proposing a new qdisc called 'cbs'. Its 'tc' cmd line is:\n> $ tc qdisc add dev IFACE parent ID cbs locredit N hicredit M sendslope S \\\n> idleslope I\n> \n> Note that the parameters for this qdisc are the ones defined by the\n> 802.1Q-2014 spec, so no hardware specific functionality is exposed here.\n\nThese parameters look good to me as a baseline; some additional optional\nparameters may be useful for software-based implementations--such as setting an\ninterval at which to recalculate queues--but those can be discussed later.\n\n> * Time-aware shaper (802.1Qbv):\n\nI haven't come across any specific NIC or SoC MAC that does Qbv, but I have\nbeen experimenting with an EspressoBin board, which has a \"Topaz\" DSA switch\nin it that has some features intended for Qbv support, although they were done\nwith a draft version in mind.\n\nI haven't looked at the interaction between the qdisc subsystem and DSA yet,\nbut this mechanism might be useful to configure Qbv on the slave ports in\nthat context. I've got both the board and the documentation, so I might be\nable to work on an implementation at some point.\n\nIf some endpoint device shows up with direct Qbv support, this interface would\nprobably work well there too, although a talker would need to be able to\nschedule its transmits pretty precisely to achieve the lowest possible latency.\n\n> The idea we are currently exploring is to add a \"time-aware\", priority based\n> qdisc, that also exposes the Tx queues available and provides a mechanism for\n> mapping priority <-> traffic class <-> Tx queues in a similar fashion as\n> mqprio. We are calling this qdisc 'taprio', and its 'tc' cmd line would be:\n> \n> $ $ tc qdisc add dev ens4 parent root handle 100 taprio num_tc 4 \\\n> \t map 2 2 1 0 3 3 3 3 3 3 3 3 3 3 3 3 \\\n> \t queues 0 1 2 3 \\\n> \t sched-file gates.sched [base-time ] \\\n> [cycle-time ] [extension-time ]\n\nOne concern here is calling the base-time parameter an interval; it's really\nan absolute time with respect to the PTP timescale. Good documentation will\nbe important to this one, since the specification discusses some subtleties\nregarding the impact of different time values chosen here.\n\nThe format for specifying the actual intervals such as cycle-time could prove\nto be an important detail as well; Qbv specifies cycle-time as a ratio of two\nintegers expressed in seconds, while extension-time is specified as an integer\nnumber of nanoseconds.\n\nPrecision with the cycle-time is especially important, since base-time can be\nalmost arbitrarily far in the past or future, and any given cycle start should\nbe calculable from the base-time plus/minus some integer multiple of cycle-\ntime.\n\n> is multi-line, with each line being of the following format:\n> \n> \n> Qbv only defines one : \"S\" for 'SetGates'\n> \n> For example:\n> \n> S 0x01 300\n> S 0x03 500\n> \n> This means that there are two intervals, the first will have the gate\n> for traffic class 0 open for 300 nanoseconds, the second will have\n> both traffic classes open for 500 nanoseconds.\n> \n> Additionally, an option to set just one entry of the gate control list will\n> also be provided by 'taprio':\n> \n> $ tc qdisc (...) \\\n> sched-row \\\n> [base-time ] [cycle-time ] \\\n> [extension-time ]\n\nIf I understand correctly, 'sched-row' is meant to be usable multiple times in\na single command and the 'sched-file' option is just a shorthand version for\nlarge tables? Or is it meant to update an existing schedule table? It doesn't\nseem very useful if it can only be specified once when the whole taprio intance\nis being established.\n\n> * Frame Preemption (802.1Qbu):\n> \n> To control even further the latency, it may prove useful to signal which\n> traffic classes are marked as preemptable. For that, 'taprio' provides the\n> preemption command so you set each traffic class as preemptable or not:\n> \n> $ tc qdisc (...) \\\n> preemption 0 1 1 1\n> \n> \n> * Time-aware shaper + Preemption:\n> \n> As an example of how Qbv and Qbu can be used together, we may specify\n> both the schedule and the preempt-mask, and this way we may also\n> specify the Set-Gates-and-Hold and Set-Gates-and-Release commands as\n> specified in the Qbu spec:\n> \n> $ tc qdisc add dev ens4 parent root handle 100 taprio num_tc 4 \\\n> \t map 2 2 1 0 3 3 3 3 3 3 3 3 3 3 3 3 \\\n> \t queues 0 1 2 3 \\\n> \t preemption 0 1 1 1 \\\n> \t sched-file preempt_gates.sched\n> \n> is multi-line, with each line being of the following format:\n> \n> \n> For this case, two new commands are introduced:\n> \n> \"H\" for 'set gates and hold'\n> \"R\" for 'set gates and release'\n> \n> H 0x01 300\n> R 0x03 500\n> \n\nThe new Hold and Release gate commands look right, but I'm not sure about the\npreemption flags. Qbu describes a preemption parameter table indexed by\n*priority* rather than traffic class or queue. These select which of two MAC\nservice interfaces is used by the frame at the ISS layer, either express or\npreemptable, at the time the frame is selected for transmit. If my\nunderstanding is correct, it's possible to map a preemptable priority as well\nas an express priority to the same queue, so flagging preemptability at the\nqueue level is not correct.\n\nI'm not aware of any endpoint interfaces that support Qbu either, nor do I \nknow of any switches that support it that someone could experiment with right\nnow, so there's no pressure on getting that interface nailed down yet.\n\nHopefully you find this feedback useful, and I appreciate the effort taken to\nget the RFC posted here!\n\nLevi","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.137; helo=fraxinus.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"ihS3eQcI\"; dkim-atps=neutral"],"Received":["from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxlc72m8pz9s82\n\tfor ;\n\tWed, 20 Sep 2017 13:29:58 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 78BD68735C;\n\tWed, 20 Sep 2017 03:29:57 +0000 (UTC)","from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id N9fukqrog0CM; Wed, 20 Sep 2017 03:29:56 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 51F63872B9;\n\tWed, 20 Sep 2017 03:29:56 +0000 (UTC)","from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\tby ash.osuosl.org (Postfix) with ESMTP id 4215C1CEBC1\n\tfor ;\n\tWed, 20 Sep 2017 01:59:22 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 349E68723D\n\tfor ;\n\tWed, 20 Sep 2017 01:59:22 +0000 (UTC)","from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id nmaZApKKr1bU for ;\n\tWed, 20 Sep 2017 01:59:21 +0000 (UTC)","from mail-pf0-f194.google.com (mail-pf0-f194.google.com\n\t[209.85.192.194])\n\tby fraxinus.osuosl.org (Postfix) with ESMTPS id 3619B871DE\n\tfor ;\n\tWed, 20 Sep 2017 01:59:21 +0000 (UTC)","by mail-pf0-f194.google.com with SMTP id g65so590629pfe.1\n\tfor ;\n\tTue, 19 Sep 2017 18:59:21 -0700 (PDT)","from brute.local (c-98-202-130-141.hsd1.ut.comcast.net.\n\t[98.202.130.141]) by smtp.gmail.com with ESMTPSA id\n\ta1sm6909512pgu.47.2017.09.19.18.59.18\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 19 Sep 2017 18:59:19 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=from:to:cc:subject:date:message-id:in-reply-to:references;\n\tbh=iOVVEHpsOoVeMtEQTI6PBCF7ssICtjSnGtdHU8ry0+I=;\n\tb=ihS3eQcIabztC8ziuufAsz7GWOgRv3n0mDidkRjrPgPB3AvrBr1JCaR2g1xm4/zCZk\n\t1rgT2lFfpHbdeIuslyG7ZJzpbTMXw/xB1an9PCVeFH36ZlvzZJEp+++Bv03ZArV4pA/P\n\tARccXOx+EM6HxGOrrKrSYeWu/a3p4C4bpdk8I1roM/xAZHY4LS9dMXoZpZVPe8+jQM3p\n\tpq4obkk6WWA8DtX8Kx1AYP0RWPuT+mQJocTgpTV4u0waXt6WLoiVCQwwYFAiduSH+ANk\n\tAfEAq2NE3cdExiskCVkX78wKYNFjjBWw+v2cwb9NjIilJ2Wb9ZztnzCVK8C2CqdlvIYf\n\tmELA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to\n\t:references;\n\tbh=iOVVEHpsOoVeMtEQTI6PBCF7ssICtjSnGtdHU8ry0+I=;\n\tb=NtxS9ZFfzjF0s/RAhWsa5KNCDMgBAQqxnCWzvXFROkyLgFLafb8/aTQdLYxXXTF9CT\n\t+5SqEY8DLIATbAhTKbBrjLI3Icb8O+4nJ7i6oqfvY2JDF44iMXQ3LwST/E5/PHuZCCAR\n\tGcYwVdlgMlD5ufww0gsqzjR0g3xwNbANTcBMHPrv5pKX7tmOjPB5Xb/e8XkdPKqJN2R0\n\tHvHdkwKz5qbOq1ZgSSMCC3lAm240y/o95AXAplIgQMrtARviAMXL7Br/NCozrJoLKk3K\n\tjDWevSjrUZ1xP97OJX6R6AvCnHbe+kD6VShEAXRfcuI3sPZ4N+69FkgNzLepq0hNTLQP\n\tYgVw==","X-Gm-Message-State":"AHPjjUhEKHgcIvdWKS5ezutFe61u20Knsnhi8PLptfka/TGOG/yDG9pS\n\tHPGs2/4qAkYRQoEeD84Tj5w=","X-Google-Smtp-Source":"AOwi7QAWINu/mMsccNskgatDQT8hyrti6tIaA/VDu/pJYz6YL1YIAMkzUGhNs7lhu4PwslPD0UbJvw==","X-Received":"by 10.159.252.75 with SMTP id t11mr501861plz.441.1505872760606; \n\tTue, 19 Sep 2017 18:59:20 -0700 (PDT)","From":"levipearson@gmail.com","To":"vinicius.gomes@intel.com","Date":"Tue, 19 Sep 2017 19:59:11 -0600","Message-Id":"<20170920015911.18999-1-levipearson@gmail.com>","X-Mailer":"git-send-email 2.14.1","In-Reply-To":"<20170901012625.14838-1-vinicius.gomes@intel.com>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>","X-Mailman-Approved-At":"Wed, 20 Sep 2017 03:29:55 +0000","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, richardcochran@gmail.com, henrik@austad.us,\n\tjhs@mojatatu.com, intel-wired-lan@lists.osuosl.org,\n\tboon.leong.ong@intel.com, \n\txiyou.wangcong@gmail.com, jesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1771575,"web_url":"http://patchwork.ozlabs.org/comment/1771575/","msgid":"<20170920052558.h6c4lkqmzk2h2pdq@localhost>","list_archive_url":null,"date":"2017-09-20T05:25:58","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":4009,"url":"http://patchwork.ozlabs.org/api/people/4009/","name":"Richard Cochran","email":"richardcochran@gmail.com"},"content":"On Tue, Sep 19, 2017 at 05:19:18PM -0700, Vinicius Costa Gomes wrote:\n> One of the problems with OpenAVNU is that it's too coupled with the i210\n> NIC. One of the things we want is to decouple OpenAVNU from the\n> controller.\n\nYes, I want that, too.\n\n> The way we thought best was to propose interfaces (that\n> would work along side to the Linux networking stack) as close as\n> possible to what the current standards define, that means the IEEE\n> 802.1Q family of specifications, in the hope that network controller\n> vendors would also look at the specifications when designing their\n> controllers.\n\nThese standard define the *behavior*, not the programming APIs. Our\ntask as kernel developers is to invent the best interfaces for\nsupporting 802.1Q and other standards, the hardware capabilities, and\nthe widest range of applications (not jut AVB).\n\n> Our objective with the Qdiscs we are proposing (both cbs and taprio) is\n> to provide a sane way to configure controllers that support TSN features\n> (we were looking specifically at the IEEE specs).\n\nI can see how your proposed Qdiscs are inspired by the IEEE standards.\nHowever, in the case of time based transmission, I think there is a\nbetter way to do it, namely with SO_TXTIME (which BTW was originally\nproposed by Eric Mann).\n \n> After we have some rough consensus on the interfaces to use, then we can\n> start working on OpenAVNU.\n\nDid you see my table in the other mail? Any comments?\n\n> (Sorry if I am being annoying here, but the idea of an opaque schedule\n> is not ours, that comes from the people who wrote the Qbv specification)\n\nThe schedule is easy to implement using SO_TXTIME.\n \n> I have a question, what about a controller that doesn't provide a way to\n> set a per-packet transmission time, but it supports Qbv/Qbu. What would\n> be your proposal to configure it?\n\nSO_TXTIME will have a generic SW fallback.\n\nBTW, regarding the i210, there is no sensible way to configure both\nCBS and time based transmission at the same time. The card performs a\nlogical AND to make the launch decision. The effect of this is that\neach and every packet needs a LaunchTime, and the driver would be\nforced to guess the time for a packet before entering it into its\nqueue.\n\nSo if we end up merging CBS and SO_TXTIME, then we'll have to make\nthem exclusive of each other (in the case of the i210) and manage the\ni210 queue configurations correctly.\n\n> (I think LaunchTime is something specific to the i210, right?)\n\nTo my knowledge yes. However, if TSN does take hold, then other MAC\nvendors will copy it.\n\nThanks,\nRichard","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.137; helo=fraxinus.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"DdBSc/Uk\"; dkim-atps=neutral"],"Received":["from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxpBC4Vxgz9sBW\n\tfor ;\n\tWed, 20 Sep 2017 15:26:10 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 25C9586F0B;\n\tWed, 20 Sep 2017 05:26:09 +0000 (UTC)","from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id wGfIoKoILcNE; Wed, 20 Sep 2017 05:26:07 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id DF1A086E75;\n\tWed, 20 Sep 2017 05:26:07 +0000 (UTC)","from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id 852291BFF90\n\tfor ;\n\tWed, 20 Sep 2017 05:26:06 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id 7B8F62E779\n\tfor ;\n\tWed, 20 Sep 2017 05:26:06 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id CmCjThQ+QmxN for ;\n\tWed, 20 Sep 2017 05:26:06 +0000 (UTC)","from mail-wm0-f68.google.com (mail-wm0-f68.google.com\n\t[74.125.82.68])\n\tby silver.osuosl.org (Postfix) with ESMTPS id AC0362E6A3\n\tfor ;\n\tWed, 20 Sep 2017 05:26:05 +0000 (UTC)","by mail-wm0-f68.google.com with SMTP id i131so1369847wma.1\n\tfor ;\n\tTue, 19 Sep 2017 22:26:05 -0700 (PDT)","from localhost (213-225-0-7.nat.highway.a1.net. [213.225.0.7])\n\tby smtp.gmail.com with ESMTPSA id\n\t29sm944319wrz.77.2017.09.19.22.26.01\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tTue, 19 Sep 2017 22:26:02 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=hoqFyyKKUEO9mZK/anJDaQ+axuwc2r8v0MsstUMGFso=;\n\tb=DdBSc/Uk1dd/CQNoOtlG6tweV2daU787NbXG8gvT5/4ew97H3Dta6kktKvewvQm5ZT\n\txyMTccUGu9p+fdPhuGmCdCXyoUCWdMyhC9pbiYnrlZfcfnM6gIz/du1q40elkusXTqHh\n\tEM9LC5m+2ekofyDF8hDDl6mWmcHETTSmRAfLD08G1Db2F4wOzwrO22i1gCc7Hk1RYXJs\n\td/OqmRMS7Q0tgrKZ98HdDy4NsH/qAoOzUtBJEspyBmZMR3YX/733m+z74EIlJq3VBXI/\n\t0Svt5tSl2HfBHqXB5aEPUKM97r8i4ja/l15FfVFsIbZEI0+cHJKXgBcJBlpETMrMMDNC\n\tIdnw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=hoqFyyKKUEO9mZK/anJDaQ+axuwc2r8v0MsstUMGFso=;\n\tb=TCq+FpGKZGX0SrBx0jp3aYR+AAuSarKgVfzF2Oc2lRWybqyjrK/6/nmAavyASEU3Tu\n\tFsqIBJtVCcMS1UeGmibIS2hvtZwXfeMB9vrfq5MUHSB6f3v5rnY+BV5ig70IsG6GNwbE\n\t8OSREQoZfS9jI5j4BJf67s1P41gqCeIhyfPTIBv6zYjFoa5qmp/jdC1SQW1MIkEMc2Ls\n\tv3IoKpcwwCl9rYRdQNqFCwDHVnTIGpfaxNRjyYppTNOAMhi5AJHTxeX6/E4ypy5B1fJN\n\tFEdVCIth1MqRBGv9/CIIrrOq2yPUnpgbImzkndDEUdeJ7WSDe6HOYxVs3lFpELqvWyRv\n\tor8w==","X-Gm-Message-State":"AHPjjUjhT+x+D7u1Y2koMOoEE9oHhPZJr+NYC2e7yu+B1g6JLG3x3F/8\n\tcPhm/sxUn9Y5DKwDfASHpq0=","X-Google-Smtp-Source":"AOwi7QCPqqG14JlOvLXA2bRBn6GCtPj04DWJkRckKdUwR5qCDjuZwcmv46ShUOaQ4V25pAHkPr56+A==","X-Received":"by 10.28.137.208 with SMTP id l199mr2570543wmd.123.1505885164077;\n\tTue, 19 Sep 2017 22:26:04 -0700 (PDT)","Date":"Wed, 20 Sep 2017 07:25:58 +0200","From":"Richard Cochran ","To":"Vinicius Costa Gomes ","Message-ID":"<20170920052558.h6c4lkqmzk2h2pdq@localhost>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170918080214.yrejz67wwnp2pjzf@localhost>\n\t<87k20vip3f.fsf@intel.com>\n\t<20170919052244.77umdxuze53t6j22@localhost>\n\t<87wp4ufchl.fsf@intel.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<87wp4ufchl.fsf@intel.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, \n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com,\n\tjesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1771583,"web_url":"http://patchwork.ozlabs.org/comment/1771583/","msgid":"<20170920054919.jtqckuybsu42tvpk@localhost>","list_archive_url":null,"date":"2017-09-20T05:49:19","subject":"Re: [Intel-wired-lan] TSN Scorecard,\n\twas Re: [RFC net-next 0/5] TSN: Add qdisc-based config interfaces\n\tfor traffic shapers","submitter":{"id":4009,"url":"http://patchwork.ozlabs.org/api/people/4009/","name":"Richard Cochran","email":"richardcochran@gmail.com"},"content":"On Tue, Sep 19, 2017 at 11:17:54PM -0600, levipearson@gmail.com wrote:\n> In addition to OpenAvnu, Renesas has a number of github repositories with what looks like a fairly\n> complete media streaming system:\n\nIs it a generic stack or a set of hacks for their HW?\n\n> Although your SO_TXTIME proposal could certainly form the basis of an endpoint's implementation of Qbv, I\n> think it is a stretch to consider it a Qbv implementation in itself, if that's what you mean by this.\n\nNo, that is not what I meant. We need some minimal additional kernel\nsupport in order to fully implement the TSN family of standards. Of\ncourse, the bulk will have to be done in user space. It would be a\nmistake to cram the stuff that belongs in userland into the kernel.\n\nLooking at the table, and reading your descriptions of the state of\nOpenAVB, I remained convinced that the kernel needs only three\nadditions:\n\n1. SO_TXTIME\n2. CBS Qdisc\n3. ALSA support for DAC clock control (but that is another story)\n\n> The proper interfaces for the Qbv configuration and managing of switch-level PTP timestamps are not yet\n> in place, so there's nothing even at RFC stage to present yet, but Qbv-capable Linux-managed switch\n> hardware is available and we hope to get some reusable code published even if it's not yet ready to be\n> integrated in the kernel.\n\nRight, configuring Qbv in an attached DSA switch needs its own\ninterface.\n\nRegarding PHC support for DSA switches, I have something in the works\nto be published soon.\n\n> A bit of progress has been made since that was written, although it is true that it's still not\n> quite complete and certainly not turnkey.\n\nSo OpenAVB is neither complete nor turnkey. That was my impression,\ntoo.\n\n> Things are maybe a bit farther along than they seemed, but there is still important kernel work to be\n> done to reduce the need for out-of-tree drivers and to get everyone on the same interfaces. I plan\n> to be an active participant going forward.\n\nYou mentioned a couple of different kernel things you implemented.\nI would encourage you to post the work already done.\n\nThanks,\nRichard","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.137; helo=fraxinus.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"kHKAjPHb\"; dkim-atps=neutral"],"Received":["from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxpj75d6mz9s81\n\tfor ;\n\tWed, 20 Sep 2017 15:49:30 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 2012086F9C;\n\tWed, 20 Sep 2017 05:49:29 +0000 (UTC)","from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id xn7Ng7lg_9pK; Wed, 20 Sep 2017 05:49:27 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 60A1086F97;\n\tWed, 20 Sep 2017 05:49:27 +0000 (UTC)","from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id AED8A1C121F\n\tfor ;\n\tWed, 20 Sep 2017 05:49:26 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id A7D7823001\n\tfor ;\n\tWed, 20 Sep 2017 05:49:26 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id BN-Ul5KE8fzw for ;\n\tWed, 20 Sep 2017 05:49:26 +0000 (UTC)","from mail-wm0-f52.google.com (mail-wm0-f52.google.com\n\t[74.125.82.52])\n\tby silver.osuosl.org (Postfix) with ESMTPS id DF49322E96\n\tfor ;\n\tWed, 20 Sep 2017 05:49:25 +0000 (UTC)","by mail-wm0-f52.google.com with SMTP id a137so3010156wma.0\n\tfor ;\n\tTue, 19 Sep 2017 22:49:25 -0700 (PDT)","from localhost (213-225-0-7.nat.highway.a1.net. [213.225.0.7])\n\tby smtp.gmail.com with ESMTPSA id\n\ta195sm808415wme.34.2017.09.19.22.49.21\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tTue, 19 Sep 2017 22:49:22 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=DnodFMl05vBiDchDhknHzghfg+kgKu/+ICzvGdd8Lpg=;\n\tb=kHKAjPHb/0RJ2wMe4750+EMteOIcqyq+fTkGaJuEGu1v8sGUXRLGXllgfAL4+mMetb\n\tzLb3z7VI+zNM3Up/VMxH3/k0o+8E7H41iLuB46VJnupiZnT1Wkpc+JK0M0FMWiyMLHmV\n\t+oIx9PSjj86GB4/94lPLbzyAi6hTsC0zabXVIkxRFGhtbXdTogPIBIPA5ixgENs2m2Ur\n\tUW4Tk8Bcxw8muJw9KLKj4uJLBRagnoYJLO6TR8I8glWABdWmQO3aV5+DMaBf76V2F1rS\n\txzZpP4doE2eiWrmlh5QTop3BR8YFTjXG5ipOcKo3H6TBuQPztm0Y9+y/cA57afLNu29p\n\tmQkQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=DnodFMl05vBiDchDhknHzghfg+kgKu/+ICzvGdd8Lpg=;\n\tb=EqNuQCIR37V04bNeB644eD+Mhsj8rqzgDFdJEMpp3QBMMUTiM+ayrfSI384thOhX2W\n\tOu57XkrqwU8ZEWiguRd4Hy4Cz0+uoq6uDRUcjrLK/0zc+StBpE5hfCsa4U9Bauxr3tK2\n\tqgH0RflfVd92XnP0NGfVUIccc9KxfdtCCmvAllEmtaz020FOYpTGWnxF9jdflH8csjPc\n\tsxakRTE4W/1YqmCOcoglmuW4LnDyrt1Wa1FG4xdVUfuAEP7pgegG87dp/0ORkwybHtOy\n\t8GeHWUMFFyZprkUTbXKZQCDa+k1xT99UpBbFgAOcbpf2o7Kh5zqtatYxefJWlbGGte36\n\t5EiA==","X-Gm-Message-State":"AHPjjUgf4SsaYt8LRVuRgC1HpNoZKts/avQ2ULRpHfmAmdgh8XCNxaGz\n\tEu7REoPVV/+IBsczTCOmHPo=","X-Google-Smtp-Source":"AOwi7QDIcYQmQpV4IpwSNgWhriQk2nTu5vgJbcmQ1Qkv8BHNw/0JMZAse/yMzdBtzAmkCJZSXJjClg==","X-Received":"by 10.28.199.139 with SMTP id x133mr3099757wmf.43.1505886564414; \n\tTue, 19 Sep 2017 22:49:24 -0700 (PDT)","Date":"Wed, 20 Sep 2017 07:49:19 +0200","From":"Richard Cochran ","To":"levipearson@gmail.com","Message-ID":"<20170920054919.jtqckuybsu42tvpk@localhost>","References":"<20170918081248.txhars53icbqsvld@localhost>\n\t<20170920051754.21745-1-levipearson@gmail.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20170920051754.21745-1-levipearson@gmail.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, henrik@austad.us, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, boon.leong.ong@intel.com,\n\txiyou.wangcong@gmail.com, jesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] TSN Scorecard,\n\twas Re: [RFC net-next 0/5] TSN: Add qdisc-based config interfaces\n\tfor traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1771589,"web_url":"http://patchwork.ozlabs.org/comment/1771589/","msgid":"<20170920055616.snd6tndvbdnesnck@localhost>","list_archive_url":null,"date":"2017-09-20T05:56:16","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":4009,"url":"http://patchwork.ozlabs.org/api/people/4009/","name":"Richard Cochran","email":"richardcochran@gmail.com"},"content":"On Tue, Sep 19, 2017 at 07:59:11PM -0600, levipearson@gmail.com wrote:\n> If some endpoint device shows up with direct Qbv support, this interface would\n> probably work well there too, although a talker would need to be able to\n> schedule its transmits pretty precisely to achieve the lowest possible latency.\n\nThis is an argument for SO_TXTIME.\n\n> One concern here is calling the base-time parameter an interval; it's really\n> an absolute time with respect to the PTP timescale. Good documentation will\n> be important to this one, since the specification discusses some subtleties\n> regarding the impact of different time values chosen here.\n> \n> The format for specifying the actual intervals such as cycle-time could prove\n> to be an important detail as well; Qbv specifies cycle-time as a ratio of two\n> integers expressed in seconds, while extension-time is specified as an integer\n> number of nanoseconds.\n> \n> Precision with the cycle-time is especially important, since base-time can be\n> almost arbitrarily far in the past or future, and any given cycle start should\n> be calculable from the base-time plus/minus some integer multiple of cycle-\n> time.\n\nThe above three points also.\n\nThanks,\nRichard","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.133; helo=hemlock.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"N61lg11Z\"; dkim-atps=neutral"],"Received":["from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxps8054Kz9s81\n\tfor ;\n\tWed, 20 Sep 2017 15:56:27 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id E99FD87B08;\n\tWed, 20 Sep 2017 05:56:25 +0000 (UTC)","from hemlock.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id qHAjCA4tHlAG; Wed, 20 Sep 2017 05:56:24 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id 0BA1A87AFD;\n\tWed, 20 Sep 2017 05:56:24 +0000 (UTC)","from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\tby ash.osuosl.org (Postfix) with ESMTP id 2FE191C0F60\n\tfor ;\n\tWed, 20 Sep 2017 05:56:23 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 2633B88023\n\tfor ;\n\tWed, 20 Sep 2017 05:56:23 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id 1YczVD5v+Tiq for ;\n\tWed, 20 Sep 2017 05:56:22 +0000 (UTC)","from mail-wr0-f181.google.com (mail-wr0-f181.google.com\n\t[209.85.128.181])\n\tby whitealder.osuosl.org (Postfix) with ESMTPS id 5D79388014\n\tfor ;\n\tWed, 20 Sep 2017 05:56:22 +0000 (UTC)","by mail-wr0-f181.google.com with SMTP id u96so1189739wrb.6\n\tfor ;\n\tTue, 19 Sep 2017 22:56:22 -0700 (PDT)","from localhost (213-225-0-7.nat.highway.a1.net. [213.225.0.7])\n\tby smtp.gmail.com with ESMTPSA id\n\t133sm891409wmu.4.2017.09.19.22.56.18\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tTue, 19 Sep 2017 22:56:19 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=1467cX5TQas/dF/GILczG/+KnGAsrs0ksWTMlIEFbGQ=;\n\tb=N61lg11ZSUSJ1sE+VQ399oyr56IvTfzr00OeXSN+yABJYyqWrfKyjq77rFFhsgCtoI\n\t1YqQB2cpRJuFyr+7v8067b4A0arbh/IbWCIcGZnolJ2lP52YnO43CW79dwsnxDBtZj2Y\n\t45BVqKJSSl4U8oeLjojvXQXaImCJx8Z1RRGvLwvPRZ31K9h59beLa55flHJ2iw/9zV+j\n\tF7rNWERlMaOn8exd/8uHOdnUyWT4NEYVyPqbXPa8Oq3OTW1+r3g2AHuuRU008Q6xXhwT\n\tM8I+DS1WGepcIFR1YegzmPaNoVAsvOdx1co1AzaqxjlwAXSu2/SzwEOdotYMjqQUnaPS\n\tv2ig==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=1467cX5TQas/dF/GILczG/+KnGAsrs0ksWTMlIEFbGQ=;\n\tb=gAX5Rljp4GG/qZkRfHydSude2Xc0SvnTUdOM6YA1EyfE4SeD6K8heJL4XXWouM2IGy\n\tKA+LR7OrtFDQYTQ7UHAlWhZZTFlGVl17yvxCcqlJzCBJ8H+KJ83LoOR3ew6RxhXuca45\n\tJFjFfue8qvzzegN7Xnqpy7uv48ePKNuwqTmC0reNDOK2TVV82hqaT14oV9QfeXsQKW8a\n\tyXG6XJ3IHQpFm/LW6JVLeFFOZ8S5SmNNbvXbwnqKTHJ+IHzYgw8QyQd8QOFRyKzMm1bj\n\tmLJ2POE62QTmkgVaQoY9cuNB0agfpL0dU5iLh+HH6RPVjB3oDxuOw4Ih+0uWrr9zeooa\n\tNhQA==","X-Gm-Message-State":"AHPjjUigW45WkyjWuZDCyxkV1Xa77qiHbZ6ZHb7ZUbGrJoHcewruzEvv\n\ty6Vf3NHHCiE9iTsqXCuZ3g4=","X-Google-Smtp-Source":"AOwi7QD/v13mocTHU7vmePibONg6P3jGuX/Fs9OPGXfINl5T65h4uKpM1+Zw0tgxzs0xeDTlTl210w==","X-Received":"by 10.223.159.11 with SMTP id l11mr848790wrf.148.1505886980880; \n\tTue, 19 Sep 2017 22:56:20 -0700 (PDT)","Date":"Wed, 20 Sep 2017 07:56:16 +0200","From":"Richard Cochran ","To":"levipearson@gmail.com","Message-ID":"<20170920055616.snd6tndvbdnesnck@localhost>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170920015911.18999-1-levipearson@gmail.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20170920015911.18999-1-levipearson@gmail.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, henrik@austad.us, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, boon.leong.ong@intel.com,\n\txiyou.wangcong@gmail.com, jesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1771593,"web_url":"http://patchwork.ozlabs.org/comment/1771593/","msgid":"<20170920055829.bhwn6pd332ldjkeg@localhost>","list_archive_url":null,"date":"2017-09-20T05:58:29","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":4009,"url":"http://patchwork.ozlabs.org/api/people/4009/","name":"Richard Cochran","email":"richardcochran@gmail.com"},"content":"On Tue, Sep 19, 2017 at 05:19:18PM -0700, Vinicius Costa Gomes wrote:\n> (I think LaunchTime is something specific to the i210, right?)\n\nLevi just told us:\n\n Recent SoCs from NXP (the i.MX 6 SoloX, and all the i.MX 7 and 8\n parts) support Qav shaping as well as scheduled launch\n functionality;\n\nThanks,\nRichard","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"lqEsm1Dz\"; dkim-atps=neutral"],"Received":["from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxpvh5YQWz9sNr\n\tfor ;\n\tWed, 20 Sep 2017 15:58:40 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id E061182D98;\n\tWed, 20 Sep 2017 05:58:38 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id trlR1AYTBe5C; Wed, 20 Sep 2017 05:58:36 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id A1A9882947;\n\tWed, 20 Sep 2017 05:58:36 +0000 (UTC)","from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\tby ash.osuosl.org (Postfix) with ESMTP id 7B3761C0F60\n\tfor ;\n\tWed, 20 Sep 2017 05:58:35 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 72F7682947\n\tfor ;\n\tWed, 20 Sep 2017 05:58:35 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id WF3z608E0X4G for ;\n\tWed, 20 Sep 2017 05:58:34 +0000 (UTC)","from mail-wm0-f50.google.com (mail-wm0-f50.google.com\n\t[74.125.82.50])\n\tby whitealder.osuosl.org (Postfix) with ESMTPS id 279248202F\n\tfor ;\n\tWed, 20 Sep 2017 05:58:34 +0000 (UTC)","by mail-wm0-f50.google.com with SMTP id r68so3960170wmg.3\n\tfor ;\n\tTue, 19 Sep 2017 22:58:34 -0700 (PDT)","from localhost (213-225-0-7.nat.highway.a1.net. [213.225.0.7])\n\tby smtp.gmail.com with ESMTPSA id\n\td5sm852274wma.22.2017.09.19.22.58.30\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tTue, 19 Sep 2017 22:58:31 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=PUXGwl6tYFEBRlfo0cQh6BJBLlCuj+vYJXAh/wayTjE=;\n\tb=lqEsm1DzKS3forpOgfaqK2/phDnBNwEOMQRU7862c3f3p4R88ewNhCVRmsDOcPijDW\n\tT6LhHRUYS+BnASd7+Vyf6NCC9iKBAQcOUjBvPZxtM6+2OKTHvifEe9kYqtJ9HGF9FHBI\n\tjAag+eqnPa2MFvLNGMkwIE5CdPWO73lM6ugcCpcyc4vSwIac8XmIaJPY91aYj0NUHjtM\n\tD2qa0e6FjPd7QQRUNTmsrSaUA8KVTHf5OvzwmMXHLeLHLojSJqU7hjy4Qkfso0HVz5DD\n\tJ6xIsIESv8X8JC8tp05IXax6UzLkTkLmHehJOrT09QeyFcf471URYtZuGSA7j8GnAUms\n\tQvug==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=PUXGwl6tYFEBRlfo0cQh6BJBLlCuj+vYJXAh/wayTjE=;\n\tb=ANmw7cpKwctXuo3r2Mtfm7H3IaFEmBlWsZiFh7nBhY01n9RFgq3KwGXRsMp5XoxbK8\n\tIM2KnAL/Vbyj8PrW/I/Er32AuS7VJ2MDlpt1ZV8Nyj306ieBHRn2QhhTWUszktcCvNLE\n\thCVt8XeIS3F58Dh/G6Rd45ro5Bb5jV8Bh3TAAdqoEXrtwd9HjnuyRAFCK68pBbd28Gbg\n\tQlJaRuUGf9I2AFRU3lexj0o341N1Z7Zb4AYAat6JYgBt6Vi35bRxqZG+lGa8l5L9yVA0\n\tkWKVM/oobAWvraePQnBn7iIGgW+lZFjJD2dW//PCT/GknrTtLiOOvK920AY5FBlzBcH7\n\t7nzQ==","X-Gm-Message-State":"AHPjjUjD2liWcpvi4PUCMOAqJN7rFCsbXAAGkZHIhFWPmP+yKfgQtGaX\n\tr9A9nfYy+DZ6V07O38YaUe0=","X-Google-Smtp-Source":"AOwi7QC9BNgQ+VjeU1StKaNKb0+xTyX6TTq2j9obqj0PEM1Ay77PsCVnxO5IKZ/5LWQykV79N7klXw==","X-Received":"by 10.28.217.73 with SMTP id q70mr3067368wmg.9.1505887112767;\n\tTue, 19 Sep 2017 22:58:32 -0700 (PDT)","Date":"Wed, 20 Sep 2017 07:58:29 +0200","From":"Richard Cochran ","To":"Vinicius Costa Gomes ","Message-ID":"<20170920055829.bhwn6pd332ldjkeg@localhost>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170918080214.yrejz67wwnp2pjzf@localhost>\n\t<87k20vip3f.fsf@intel.com>\n\t<20170919052244.77umdxuze53t6j22@localhost>\n\t<87wp4ufchl.fsf@intel.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<87wp4ufchl.fsf@intel.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, \n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com,\n\tjesus.sanchez-palencia@intel.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1772166,"web_url":"http://patchwork.ozlabs.org/comment/1772166/","msgid":"<20170920051754.21745-1-levipearson@gmail.com>","list_archive_url":null,"date":"2017-09-20T05:17:54","subject":"[Intel-wired-lan] TSN Scorecard,\n\twas Re: [RFC net-next 0/5] TSN: Add qdisc-based config interfaces\n\tfor traffic shapers","submitter":{"id":72396,"url":"http://patchwork.ozlabs.org/api/people/72396/","name":"Levi Pearson","email":"levipearson@gmail.com"},"content":"On Mon, Sep 18, 2017, Richard Cochran wrote:\n> Just for the record, here is my score card showing the current status\n> of TSN support in Linux. Comments and corrections are more welcome.\n> \n> Thanks,\n> Richard\n> \n> \n> | FEATURE | STANDARD | STATUS |\n> |------------------------------------------------+---------------------+------------------------------|\n> | Synchronization | 802.1AS-2011 | Implemented in |\n> | | | - Linux kernel PHC subsystem |\n> | | | - linuxptp (userspace) |\n> |------------------------------------------------+---------------------+------------------------------|\n\nAn alternate implementation of the userspace portion of gPTP is also available at [1]\n\n> | Forwarding and Queuing Enhancements | 802.1Q-2014 sec. 34 | RFC posted (this thread) |\n> | for Time-Sensitive Streams (FQTSS) | | |\n> |------------------------------------------------+---------------------+------------------------------|\n> | Stream Reservation Protocol (SRP) | 802.1Q-2014 sec. 35 | in Open-AVB [1] |\n> |------------------------------------------------+---------------------+------------------------------|\n> | Audio Video Transport Protocol (AVTP) | IEEE 1722-2011 | DNE |\n> |------------------------------------------------+---------------------+------------------------------|\n> | Audio/Video Device Discovery, Enumeration, | IEEE 1722.1-2013 | jdksavdecc-c [2] |\n> | Connection Management and Control (AVDECC) | | |\n> | AVDECC Connection Management Protocol (ACMP) | | |\n> | AVDECC Enumeration and Control Protocol (AECP) | | |\n> | MAC Address Acquisition Protocol (MAAP) | | in Open-AVB |\n> |------------------------------------------------+---------------------+------------------------------|\n\nAll of the above are available to some degree in the AVTP Pipeline part of [1], specifically at this\nlocation: https://github.com/AVnu/OpenAvnu/tree/master/lib/avtp_pipeline\n\nThe code is very modular and configurable, although some parts are in better shape than others. The AVTP\nportion can use the custom userspace driver for the i210, which can be configured to use launch scheduling,\nor it can use standard kernel interfaces via sendmsg or PACKET_MMAP. It runs as-is when configured for\nstandard interfaces with any network hardware that supports gPTP. I previously implemented a CMSG-based\nlaunch time scheduling mechanism like the one you have proposed, and I have a socket backend for it that\ncould easily be ported to your proposal. It is not part of the repository yet since there's no kernel\nsupport for it outside of my prototype and your RFC.\n\nIt is currently tied to the OpenAvnu gPTP daemon rather than linuxptp, as it uses a shared memory interface\nto get the current rate-ratio and offset information between the various clocks. There may be better ways\nto do this, but that's how the initial port of the codebase was done. It would be nice to get it working\nwith linuxptp's userspace tools at some point as well, though.\n\nThe libraries under avtp_pipeline are designed to be used separately, but a simple integrated application\nis provided and is built by the CI system.\n\nIn addition to OpenAvnu, Renesas has a number of github repositories with what looks like a fairly\ncomplete media streaming system:\n\nhttps://github.com/renesas-rcar/avb-mse\nhttps://github.com/renesas-rcar/avb-streaming\nhttps://github.com/renesas-rcar/avb-applications\n\nI haven't examined them in great detail yet, though.\n\n\n> | Frame Preemption | P802.1Qbu | DNE |\n> | Scheduled Traffic | P802.1Qbv | RFC posted (SO_TXTIME) |\n> | SRP Enhancements and Performance Improvements | P802.1Qcc | DNE |\n> \n> DNE = Does Not Exist (to my knowledge)\n\nAlthough your SO_TXTIME proposal could certainly form the basis of an endpoint's implementation of Qbv, I\nthink it is a stretch to consider it a Qbv implementation in itself, if that's what you mean by this.\n\nI have been working with colleagues on some experiments relating to a Linux-controlled DSN switch\n(a Marvell Topaz) that are a part of this effort in TSN: \n\nhttp://ieee802.org/1/files/public/docs2017/tsn-cgunther-802-3cg-multidrop-0917-v01.pdf\n\nThe proper interfaces for the Qbv configuration and managing of switch-level PTP timestamps are not yet\nin place, so there's nothing even at RFC stage to present yet, but Qbv-capable Linux-managed switch\nhardware is available and we hope to get some reusable code published even if it's not yet ready to be\nintegrated in the kernel.\n\n> \n> 1. https://github.com/Avnu/OpenAvnu\n> \n> (DISCLAIMER from the website:)\n> \n> It is planned to eventually include the various packet encapsulation types,\n> protocol discovery daemons, libraries to convert media clocks to AVB clocks\n> and vice versa, and drivers.\n> \n> This repository does not include all components required to build a full\n> production AVB/TSN system (e.g. a turnkey solution to stream stored or live audio\n> or video content). Some simple example applications are provided which\n> illustrate the flow - but a professional Audio/Video system requires a full media stack\n> - including audio and video inputs and outputs, media processing elements, and\n> various graphical user interfaces. Various companies provide such integrated\n> solutions.\n\nA bit of progress has been made since that was written, although it is true that it's still not\nquite complete and certainly not turnkey. The most glaring absence at the moment is the media\nclock recovery portion of AVTP, but I am actively working on this.\n\n> \n> 2. https://github.com/jdkoftinoff/jdksavdecc-c\n\nThis is pulled in as a dependency of the AVDECC code in OpenAvnu; it's used in the command line driven\ncontroller, but not in the avtp_pipeline code that implements the endpoint AVDECC behavior. I don't think\neither are complete by any means, but they are complete enough to be mostly compliant and usable in the\nsubset of behavior they support.\n\nThe bulk of the command line controller is a clone of: https://github.com/audioscience/avdecc-lib \n\nThings are maybe a bit farther along than they seemed, but there is still important kernel work to be\ndone to reduce the need for out-of-tree drivers and to get everyone on the same interfaces. I plan\nto be an active participant going forward.\n\n\nLevi","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"FvswOQKJ\"; dkim-atps=neutral"],"Received":["from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xy8QW5mPhz9ryv\n\tfor ;\n\tThu, 21 Sep 2017 05:08:01 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 1637C89BFE;\n\tWed, 20 Sep 2017 19:08:00 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id ISdT6KA2DM2c; Wed, 20 Sep 2017 19:07:57 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 36F7789BFD;\n\tWed, 20 Sep 2017 19:07:57 +0000 (UTC)","from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\tby ash.osuosl.org (Postfix) with ESMTP id 532111C121F\n\tfor ;\n\tWed, 20 Sep 2017 05:18:07 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 49DD387A43\n\tfor ;\n\tWed, 20 Sep 2017 05:18:07 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id A8GW0Elj3zLd for ;\n\tWed, 20 Sep 2017 05:18:05 +0000 (UTC)","from mail-pg0-f66.google.com (mail-pg0-f66.google.com\n\t[74.125.83.66])\n\tby whitealder.osuosl.org (Postfix) with ESMTPS id 233288885E\n\tfor ;\n\tWed, 20 Sep 2017 05:18:05 +0000 (UTC)","by mail-pg0-f66.google.com with SMTP id d8so1061705pgt.3\n\tfor ;\n\tTue, 19 Sep 2017 22:18:05 -0700 (PDT)","from brute.local (c-98-202-130-141.hsd1.ut.comcast.net.\n\t[98.202.130.141]) by smtp.gmail.com with ESMTPSA id\n\tr12sm5267598pgp.81.2017.09.19.22.18.02\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 19 Sep 2017 22:18:03 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=from:to:cc:subject:date:message-id:in-reply-to:references;\n\tbh=XcgCKilR8MzUi0+k5n15WhZ83Uu5rBctb3EEg7YAeJ0=;\n\tb=FvswOQKJSCu93XecfSg2Fgf4A20NZy2VDVg4fJdk25ny4KarIImbanlGAsFmcT3JYY\n\t6O11UpYke+bCsmSv2KvbcI5h2NHGKIjKDQwQ6sRZvzdvcQ5KsD5OT4kahRKFtd1fw/a9\n\t5FS+DuNTnL5Jeckka1HwNYz+9nwjw8JsCy3ilaWnv+y8cEoU1IvW8AGWDXbICxaJkZEe\n\tqKl/WkpAdJyIjsmj+ETL7y9Zpz4mHb6nXAeYOF7keC4pKoEWJ353GbN0pHxnRXoGzZnm\n\tc7kNOntJH+prt95+l48QtxD3a2HTtXeG6ASX80/BkPuAq9koSFmEIWesPivtMcMH8Tee\n\tjCxg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to\n\t:references;\n\tbh=XcgCKilR8MzUi0+k5n15WhZ83Uu5rBctb3EEg7YAeJ0=;\n\tb=X+Gc4FKF+6dJhJ4NKicgWALhjJg0ZSKJ3RIqizvusCShbS1Z9NYY4KEwCenHwVuc8M\n\tviGLzivRHK+M1gC/Ah4cgVstbTjKh3l4QO97lxulxgsCuJVXHM3rhK9wu5qPHh88T8mS\n\tqdmAwPl0XRgWKSEhM/n1C6QguISh30e2Y4zZ84j5+C5RoTGjQ7hqwyC4xMkhIp589NB9\n\ttIbW7UgQyNHSd1LqjLogXpgyx2Kj2Ey1wWXePqvV88424ex21GEltl+OjVy671S2r5ZW\n\tDIx3pip3CVpzwus06EPxI2eV65RxDo1O9LlaHRGB49wcODe25pGljKyq/W0fKf68EXyS\n\tlGmg==","X-Gm-Message-State":"AHPjjUjgZd/ezKCPfEvQziJiBvRebuEeZo1ZoThvEi8bZC0yF0NUCRaC\n\tLRuF6mmjfKa4HJ2CjkwHNSM=","X-Google-Smtp-Source":"AOwi7QAZ/pVo6EBiPIgGZSyU72RUaAZ7m+vXZtku2YjRx8Q1SIJ5ssGC/pqglp8d/9jUE602NjjNCg==","X-Received":"by 10.98.89.151 with SMTP id k23mr964548pfj.69.1505884684470;\n\tTue, 19 Sep 2017 22:18:04 -0700 (PDT)","From":"levipearson@gmail.com","To":"richardcochran@gmail.com","Date":"Tue, 19 Sep 2017 23:17:54 -0600","Message-Id":"<20170920051754.21745-1-levipearson@gmail.com>","X-Mailer":"git-send-email 2.14.1","In-Reply-To":"<20170918081248.txhars53icbqsvld@localhost>","References":"<20170918081248.txhars53icbqsvld@localhost>","X-Mailman-Approved-At":"Wed, 20 Sep 2017 19:07:56 +0000","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, henrik@austad.us, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, boon.leong.ong@intel.com,\n\txiyou.wangcong@gmail.com, jesus.sanchez-palencia@intel.com","Subject":"[Intel-wired-lan] TSN Scorecard,\n\twas Re: [RFC net-next 0/5] TSN: Add qdisc-based config interfaces\n\tfor traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1772271,"web_url":"http://patchwork.ozlabs.org/comment/1772271/","msgid":"","list_archive_url":null,"date":"2017-09-20T21:29:51","subject":"Re: [Intel-wired-lan] TSN Scorecard,\n\twas Re: [RFC net-next 0/5] TSN: Add qdisc-based config interfaces\n\tfor traffic shapers","submitter":{"id":72279,"url":"http://patchwork.ozlabs.org/api/people/72279/","name":"Jesus Sanchez-Palencia","email":"jesus.sanchez-palencia@intel.com"},"content":"Hi,\n\n\nOn 09/19/2017 10:49 PM, Richard Cochran wrote:\n(...)\n\n> \n> No, that is not what I meant. We need some minimal additional kernel\n> support in order to fully implement the TSN family of standards. Of\n> course, the bulk will have to be done in user space. It would be a\n> mistake to cram the stuff that belongs in userland into the kernel.\n> \n> Looking at the table, and reading your descriptions of the state of\n> OpenAVB, I remained convinced that the kernel needs only three\n> additions:\n> \n> 1. SO_TXTIME\n> 2. CBS Qdisc\n> 3. ALSA support for DAC clock control (but that is another story)\n\n\nWe'll be posting the CBS v1 series for review soon.\n\nThe current SO_TXTIME RFC for the purpose of Launchtime looks great, and we are\nlooking forward for the v1 + its companion qdisc so we can test / review and\nprovide feedback.\n\nWe are still under the impression that a config interface for HW offload of Qbv\n/ Qbu config will be needed, but we'll be deferring the 'taprio' proposal until\nthere are NICs (end stations) that support these standards available. We can\nrevisit it if that ever happens, and if it's still needed, but then taking into\naccount SO_TXTIME (and its related qdisc).\n\nThanks everyone for all the feedback so far.\n\nRegards,\nJesus","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.133; helo=hemlock.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","Received":["from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xyCk56MWtz9ryv\n\tfor ;\n\tThu, 21 Sep 2017 07:36:44 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id 34081895FD;\n\tWed, 20 Sep 2017 21:36:42 +0000 (UTC)","from hemlock.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id xQk5iML5vnSe; Wed, 20 Sep 2017 21:36:41 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id 84D2A895F3;\n\tWed, 20 Sep 2017 21:36:41 +0000 (UTC)","from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id 8A3191C0B21\n\tfor ;\n\tWed, 20 Sep 2017 21:36:40 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id 80C022FBF4\n\tfor ;\n\tWed, 20 Sep 2017 21:36:40 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id fzYD561dOyBq for ;\n\tWed, 20 Sep 2017 21:36:39 +0000 (UTC)","from mga14.intel.com (mga14.intel.com [192.55.52.115])\n\tby silver.osuosl.org (Postfix) with ESMTPS id BAB292FAF6\n\tfor ;\n\tWed, 20 Sep 2017 21:36:39 +0000 (UTC)","from orsmga001.jf.intel.com ([10.7.209.18])\n\tby fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t20 Sep 2017 14:36:38 -0700","from darjeeling.jf.intel.com (HELO [10.24.15.164]) ([10.24.15.164])\n\tby orsmga001.jf.intel.com with ESMTP; 20 Sep 2017 14:36:37 -0700"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos; i=\"5.42,422,1500966000\"; d=\"scan'208\";\n\ta=\"1174275873\"","To":"Richard Cochran , levipearson@gmail.com","References":"<20170918081248.txhars53icbqsvld@localhost>\n\t<20170920051754.21745-1-levipearson@gmail.com>\n\t<20170920054919.jtqckuybsu42tvpk@localhost>","From":"Jesus Sanchez-Palencia ","Message-ID":"","Date":"Wed, 20 Sep 2017 14:29:51 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170920054919.jtqckuybsu42tvpk@localhost>","Content-Language":"en-US","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, henrik@austad.us, jhs@mojatatu.com,\n\tintel-wired-lan@lists.osuosl.org, boon.leong.ong@intel.com,\n\txiyou.wangcong@gmail.com","Subject":"Re: [Intel-wired-lan] TSN Scorecard,\n\twas Re: [RFC net-next 0/5] TSN: Add qdisc-based config interfaces\n\tfor traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1790024,"web_url":"http://patchwork.ozlabs.org/comment/1790024/","msgid":"<62f3eae4-bf6a-1475-936f-5011c9ff381e@intel.com>","list_archive_url":null,"date":"2017-10-18T22:37:35","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":72279,"url":"http://patchwork.ozlabs.org/api/people/72279/","name":"Jesus Sanchez-Palencia","email":"jesus.sanchez-palencia@intel.com"},"content":"Hi Richard,\n\n\nOn 09/19/2017 10:25 PM, Richard Cochran wrote:\n(...)\n> \n>> I have a question, what about a controller that doesn't provide a way to\n>> set a per-packet transmission time, but it supports Qbv/Qbu. What would\n>> be your proposal to configure it?\n> \n> SO_TXTIME will have a generic SW fallback.\n> \n> BTW, regarding the i210, there is no sensible way to configure both\n> CBS and time based transmission at the same time. The card performs a\n> logical AND to make the launch decision. The effect of this is that\n> each and every packet needs a LaunchTime, and the driver would be\n> forced to guess the time for a packet before entering it into its\n> queue.\n> \n> So if we end up merging CBS and SO_TXTIME, then we'll have to make\n> them exclusive of each other (in the case of the i210) and manage the\n> i210 queue configurations correctly.\n> \n\nI've ran some quick tests here having launch time enabled on i210 + our cbs\npatchset. When valid Launch times are set on each packet you still get the\nexpected behavior, so I'm not sure we should just make them exclusive of each other.\n\nI also did some tests with when you don't set valid launch times, but here using\nyour idea from above, so with the driver calculating a valid launch time (i.e.\ncurrent NIC time + X ns, varying X across tests) for packets that didn't have it\nset by the user, and I wasn't too happy with its reliability. It could\ndefinitely be improved, but it has left me wondering: instead, what about\ndocumenting that if you enable TXTIME, then you *must* provide a valid Launch\ntime for all packets on traffic classes that are affected?\n\nWith the SO_TXTIME qdisc idea in place, that could even be enforced before\npackets were enqueued into the netdevice.\n\n\nRegards,\nJesus","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.136; helo=silver.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","Received":["from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yHRw31c5Yz9t4c\n\tfor ;\n\tThu, 19 Oct 2017 09:45:07 +1100 (AEDT)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id 7448630237;\n\tWed, 18 Oct 2017 22:45:05 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id x-v-I0MfAwao; Wed, 18 Oct 2017 22:45:04 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby silver.osuosl.org (Postfix) with ESMTP id B84C930229;\n\tWed, 18 Oct 2017 22:45:04 +0000 (UTC)","from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id 5682B1BFC3F\n\tfor ;\n\tWed, 18 Oct 2017 22:45:03 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id 4DB1330229\n\tfor ;\n\tWed, 18 Oct 2017 22:45:03 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id bpY-Sxju22Ix for ;\n\tWed, 18 Oct 2017 22:45:02 +0000 (UTC)","from mga14.intel.com (mga14.intel.com [192.55.52.115])\n\tby silver.osuosl.org (Postfix) with ESMTPS id 8ED0730222\n\tfor ;\n\tWed, 18 Oct 2017 22:45:02 +0000 (UTC)","from orsmga004.jf.intel.com ([10.7.209.38])\n\tby fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t18 Oct 2017 15:45:01 -0700","from darjeeling.jf.intel.com (HELO [10.7.159.56]) ([10.7.159.56])\n\tby orsmga004.jf.intel.com with ESMTP; 18 Oct 2017 15:45:01 -0700"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.43,398,1503385200\"; d=\"scan'208\";a=\"139816136\"","To":"Richard Cochran ","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170918080214.yrejz67wwnp2pjzf@localhost>\n\t<87k20vip3f.fsf@intel.com>\n\t<20170919052244.77umdxuze53t6j22@localhost>\n\t<87wp4ufchl.fsf@intel.com>\n\t<20170920052558.h6c4lkqmzk2h2pdq@localhost>","From":"Jesus Sanchez-Palencia ","Message-ID":"<62f3eae4-bf6a-1475-936f-5011c9ff381e@intel.com>","Date":"Wed, 18 Oct 2017 15:37:35 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170920052558.h6c4lkqmzk2h2pdq@localhost>","Content-Language":"en-US","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, Henrik Austad ,\n\tjhs@mojatatu.com, \n\tLevi Pearson , intel-wired-lan@lists.osuosl.org,\n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1790895,"web_url":"http://patchwork.ozlabs.org/comment/1790895/","msgid":"<20171019203949.pyv44i5sy6lnuavh@localhost>","list_archive_url":null,"date":"2017-10-19T20:39:49","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":4009,"url":"http://patchwork.ozlabs.org/api/people/4009/","name":"Richard Cochran","email":"richardcochran@gmail.com"},"content":"On Wed, Oct 18, 2017 at 03:37:35PM -0700, Jesus Sanchez-Palencia wrote:\n> I also did some tests with when you don't set valid launch times, but here using\n> your idea from above, so with the driver calculating a valid launch time (i.e.\n> current NIC time + X ns, varying X across tests) for packets that didn't have it\n> set by the user, and I wasn't too happy with its reliability. It could\n> definitely be improved, but it has left me wondering: instead, what about\n> documenting that if you enable TXTIME, then you *must* provide a valid Launch\n> time for all packets on traffic classes that are affected?\n\nIf txtime is enabled, then CBS is pointless because the txtime already\nspecifies the bandwidth implicitly.\n\nThe problem is when one program uses txtime and another uses CBS, then\nthe CBS user will experience really wrong performance.\n\nThanks,\nRichard","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.136; helo=silver.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"oPQ5w9fj\"; dkim-atps=neutral"],"Received":["from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yJ15C1ww6z9t5x\n\tfor ;\n\tFri, 20 Oct 2017 07:39:59 +1100 (AEDT)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id E4A712CF92;\n\tThu, 19 Oct 2017 20:39:38 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id SpeSxDTMilrv; Thu, 19 Oct 2017 20:39:37 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby silver.osuosl.org (Postfix) with ESMTP id A3280261E0;\n\tThu, 19 Oct 2017 20:39:37 +0000 (UTC)","from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\tby ash.osuosl.org (Postfix) with ESMTP id B83BC1C290F\n\tfor ;\n\tThu, 19 Oct 2017 20:39:54 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id A684287B5D\n\tfor ;\n\tThu, 19 Oct 2017 20:39:54 +0000 (UTC)","from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id AARJ2JPFYsId for ;\n\tThu, 19 Oct 2017 20:39:53 +0000 (UTC)","from mail-pf0-f177.google.com (mail-pf0-f177.google.com\n\t[209.85.192.177])\n\tby fraxinus.osuosl.org (Postfix) with ESMTPS id 7241087ADE\n\tfor ;\n\tThu, 19 Oct 2017 20:39:53 +0000 (UTC)","by mail-pf0-f177.google.com with SMTP id n14so7668992pfh.8\n\tfor ;\n\tThu, 19 Oct 2017 13:39:53 -0700 (PDT)","from localhost ([12.247.123.130]) by smtp.gmail.com with ESMTPSA id\n\tm10sm23470074pgs.77.2017.10.19.13.39.51\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tThu, 19 Oct 2017 13:39:52 -0700 (PDT)"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=KXKg90yiXbONv6BDE4Vousrijwv3nLH8PkAUV+ggkxI=;\n\tb=oPQ5w9fjoURheR6BSbPZWp35h70SJiikGFv0I/kEc8bXyPkgpuMvlJMFjQYmlj+aR1\n\tFJedrzk/YFJNB53vnAa6gPBvO0liUP6m4IkMIofqnGcBl+G8lfSdddnDQNQRTp790QDl\n\tBlMMG70Nb48RJxL+JfMf204HN4xaDwSrm2rh7hOcR9AoouQRAbN9ueHVEEflZG+iO/S0\n\tfp2y+SVwJNVqSCcvIhzdYJyAm7ku7KHSoBrp5I45c66owEkTR2vLS8BdOgcn6JLZXldN\n\tWqmbG8w19LEJeb8sF/AtC/CE7W2m9Yetr1S8EarsCxdtOKhft7aWpNeTVnIM4mChSSHz\n\tgyLg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=KXKg90yiXbONv6BDE4Vousrijwv3nLH8PkAUV+ggkxI=;\n\tb=YKibqqEb6Tkmrhe/eAop4eSoe03GwkGFPnK/pP8Dao6R/TO6DesA5NeQvqHk5yqzTp\n\triH1EvrOnqRFhTGo0EN6x71h3vSsF5eQECpbV2jLSHLi4Uau36fVOH4qXi66KcePFnS9\n\t+q3VjgkBATr0TtiOLhspnyXrVOMsQC+g28n+FvDNRKErrB8bNed5nvnQZ0Akw5p5Gt4b\n\tM18m2lflevxE/1o/ir4zF9Ibdnuun6zVf6N863i76Q5yzidVQ40Ofs3eUJCb6hU9H+KK\n\tEXVrpCTMA6YGRChrxd1ZCtbc9xeURHv6jGTrKS2C/2ChEnpP5NlyFV8wk46/dWG1NdlR\n\tOh+w==","X-Gm-Message-State":"AMCzsaU/kUIaKgUfLKwr0bY+YziBayjrjl77hG7qrx58m8LM2v5Ac0eA\n\tvaGm1pXZnDe3LKcOr909iZ4=","X-Google-Smtp-Source":"ABhQp+RZSHEx0U7YcrDgYH3I5U02e3BZriBi8gHSSaefUBVIol//mn6Ezx21RlefycY7fT1HOc21Cg==","X-Received":"by 10.99.96.141 with SMTP id u135mr2434613pgb.316.1508445592978; \n\tThu, 19 Oct 2017 13:39:52 -0700 (PDT)","Date":"Thu, 19 Oct 2017 13:39:49 -0700","From":"Richard Cochran ","To":"Jesus Sanchez-Palencia ","Message-ID":"<20171019203949.pyv44i5sy6lnuavh@localhost>","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170918080214.yrejz67wwnp2pjzf@localhost>\n\t<87k20vip3f.fsf@intel.com>\n\t<20170919052244.77umdxuze53t6j22@localhost>\n\t<87wp4ufchl.fsf@intel.com>\n\t<20170920052558.h6c4lkqmzk2h2pdq@localhost>\n\t<62f3eae4-bf6a-1475-936f-5011c9ff381e@intel.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<62f3eae4-bf6a-1475-936f-5011c9ff381e@intel.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, Henrik Austad ,\n\tjhs@mojatatu.com, \n\tLevi Pearson , intel-wired-lan@lists.osuosl.org,\n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":1792698,"web_url":"http://patchwork.ozlabs.org/comment/1792698/","msgid":"","list_archive_url":null,"date":"2017-10-23T17:18:43","subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","submitter":{"id":72279,"url":"http://patchwork.ozlabs.org/api/people/72279/","name":"Jesus Sanchez-Palencia","email":"jesus.sanchez-palencia@intel.com"},"content":"Hi,\n\nOn 10/19/2017 01:39 PM, Richard Cochran wrote:\n> On Wed, Oct 18, 2017 at 03:37:35PM -0700, Jesus Sanchez-Palencia wrote:\n>> I also did some tests with when you don't set valid launch times, but here using\n>> your idea from above, so with the driver calculating a valid launch time (i.e.\n>> current NIC time + X ns, varying X across tests) for packets that didn't have it\n>> set by the user, and I wasn't too happy with its reliability. It could\n>> definitely be improved, but it has left me wondering: instead, what about\n>> documenting that if you enable TXTIME, then you *must* provide a valid Launch\n>> time for all packets on traffic classes that are affected?\n> \n> If txtime is enabled, then CBS is pointless because the txtime already\n> specifies the bandwidth implicitly.\n\n\nAssuming there is no \"interfering\" traffic on that traffic class, yes.\nOtherwise, CBS could be configured just to avoid that outbound traffic ever goes\nbeyond the reserved bandwidth.\n\n\n> \n> The problem is when one program uses txtime and another uses CBS, then\n> the CBS user will experience really wrong performance.\n\n\nGood point. We'll need to adjust the launch time for controllers that behave\nlike the i210 then, imo.\n\n\nThanks,\nJesus\n\n\n> \n> Thanks,\n> Richard\n>","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.136; helo=silver.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=)","Received":["from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yLNbt5NfDz9t6F\n\tfor ;\n\tTue, 24 Oct 2017 04:26:18 +1100 (AEDT)","from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id F34F22FD8B;\n\tMon, 23 Oct 2017 17:26:16 +0000 (UTC)","from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id j+SNehL38yg9; Mon, 23 Oct 2017 17:26:15 +0000 (UTC)","from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby silver.osuosl.org (Postfix) with ESMTP id 69A422FD8A;\n\tMon, 23 Oct 2017 17:26:15 +0000 (UTC)","from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\tby ash.osuosl.org (Postfix) with ESMTP id 258D81C3F9F\n\tfor ;\n\tMon, 23 Oct 2017 17:26:14 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 1CBFF872F6\n\tfor ;\n\tMon, 23 Oct 2017 17:26:14 +0000 (UTC)","from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id aVygI67P3eja for ;\n\tMon, 23 Oct 2017 17:26:13 +0000 (UTC)","from mga03.intel.com (mga03.intel.com [134.134.136.65])\n\tby whitealder.osuosl.org (Postfix) with ESMTPS id 5C89E8727F\n\tfor ;\n\tMon, 23 Oct 2017 17:26:13 +0000 (UTC)","from orsmga005.jf.intel.com ([10.7.209.41])\n\tby orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t23 Oct 2017 10:26:12 -0700","from darjeeling.jf.intel.com (HELO [10.7.159.56]) ([10.7.159.56])\n\tby orsmga005.jf.intel.com with ESMTP; 23 Oct 2017 10:26:12 -0700"],"X-Virus-Scanned":["amavisd-new at osuosl.org","amavisd-new at osuosl.org"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.43,424,1503385200\"; d=\"scan'208\";a=\"163901511\"","To":"Richard Cochran ","References":"<20170901012625.14838-1-vinicius.gomes@intel.com>\n\t<20170918080214.yrejz67wwnp2pjzf@localhost>\n\t<87k20vip3f.fsf@intel.com>\n\t<20170919052244.77umdxuze53t6j22@localhost>\n\t<87wp4ufchl.fsf@intel.com>\n\t<20170920052558.h6c4lkqmzk2h2pdq@localhost>\n\t<62f3eae4-bf6a-1475-936f-5011c9ff381e@intel.com>\n\t<20171019203949.pyv44i5sy6lnuavh@localhost>","From":"Jesus Sanchez-Palencia ","Message-ID":"","Date":"Mon, 23 Oct 2017 10:18:43 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20171019203949.pyv44i5sy6lnuavh@localhost>","Content-Language":"en-US","Cc":"andre.guedes@intel.com, jiri@resnulli.us, ivan.briano@intel.com,\n\tnetdev@vger.kernel.org, Henrik Austad ,\n\tjhs@mojatatu.com, \n\tLevi Pearson , intel-wired-lan@lists.osuosl.org,\n\tboon.leong.ong@intel.com, xiyou.wangcong@gmail.com","Subject":"Re: [Intel-wired-lan] [RFC net-next 0/5] TSN: Add qdisc-based\n\tconfig interfaces for traffic shapers","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.18-1","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n\t","List-Unsubscribe":", \n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":", \n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}}]