[{"id":1761392,"web_url":"http://patchwork.ozlabs.org/comment/1761392/","msgid":"<20170901000502.GB28960@lunn.ch>","list_archive_url":null,"date":"2017-09-01T00:05:02","subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"On Wed, Aug 30, 2017 at 05:18:44PM -0700, Florian Fainelli wrote:\n> This patch series is sent as reference, especially because the last patch\n> is trying not to be creating too many layer violations, but clearly there\n> are a little bit being created here anyways.\n> \n> Essentially what I am trying to achieve is that you have a stacked device which\n> is multi-queue aware, that applications will be using, and for which they can\n> control the queue selection (using mq) the way they want. Each of each stacked\n> network devices are created for each port of the switch (this is what DSA\n> does). When a skb is submitted from say net_device X, we can derive its port\n> number and look at the queue_mapping value to determine which port of the\n> switch and queue we should be sending this to. The information is embedded in a\n> tag (4 bytes) and is used by the switch to steer the transmission.\n> \n> These stacked devices will actually transmit using a \"master\" or conduit\n> network device which has a number of queues as well. In one version of the\n> hardware that I work with, we have up to 4 ports, each with 8 queues, and the\n> master device has a total of 32 hardware queues, so a 1:1 mapping is easy. With\n> another version of the hardware, same number of ports and queues, but only 16\n> hardware queues, so only a 2:1 mapping is possible.\n> \n> In order for congestion information to work properly, I need to establish a\n> mapping, preferably before transmission starts (but reconfiguration while\n> interfaces are running would be possible too) between these stacked device's\n> queue and the conduit interface's queue.\n> \n> Comments, flames, rotten tomatoes, anything!\n\nRight, i think i understand.\n\nThis works just for traffic between the host and ports. The host can\nset the egress queue. And i assume the queues are priorities, either\nabsolute or weighted round robin, etc.\n\nBut this has no effect on traffic going from port to port. At some\npoint, i expect you will want to offload TC for that.\n\nHow will the two interact? Could the TC rules also act on traffic from\nthe host to a port? Would it be simpler in the long run to just\nimplement TC rules?\n\n\t Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xjzyY6cYQz9s7p\n\tfor ;\n\tFri, 1 Sep 2017 10:05:09 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751651AbdIAAFG (ORCPT );\n\tThu, 31 Aug 2017 20:05:06 -0400","from vps0.lunn.ch ([178.209.37.122]:47640 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751242AbdIAAFF (ORCPT );\n\tThu, 31 Aug 2017 20:05:05 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dnZSI-0000LY-VC; Fri, 01 Sep 2017 02:05:02 +0200"],"Date":"Fri, 1 Sep 2017 02:05:02 +0200","From":"Andrew Lunn ","To":"Florian Fainelli ","Cc":"netdev@vger.kernel.org, jiri@resnulli.us, jhs@mojatatu.com,\n\tdavem@davemloft.net, xiyou.wangcong@gmail.com,\n\tvivien.didelot@savoirfairelinux.com","Subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","Message-ID":"<20170901000502.GB28960@lunn.ch>","References":"<1504138732-65383-1-git-send-email-f.fainelli@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1504138732-65383-1-git-send-email-f.fainelli@gmail.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761460,"web_url":"http://patchwork.ozlabs.org/comment/1761460/","msgid":"<7d738ef5-c312-e0b3-3605-1f31fa7dc019@gmail.com>","list_archive_url":null,"date":"2017-09-01T04:10:55","subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 08/31/2017 05:05 PM, Andrew Lunn wrote:\n> On Wed, Aug 30, 2017 at 05:18:44PM -0700, Florian Fainelli wrote:\n>> This patch series is sent as reference, especially because the last patch\n>> is trying not to be creating too many layer violations, but clearly there\n>> are a little bit being created here anyways.\n>>\n>> Essentially what I am trying to achieve is that you have a stacked device which\n>> is multi-queue aware, that applications will be using, and for which they can\n>> control the queue selection (using mq) the way they want. Each of each stacked\n>> network devices are created for each port of the switch (this is what DSA\n>> does). When a skb is submitted from say net_device X, we can derive its port\n>> number and look at the queue_mapping value to determine which port of the\n>> switch and queue we should be sending this to. The information is embedded in a\n>> tag (4 bytes) and is used by the switch to steer the transmission.\n>>\n>> These stacked devices will actually transmit using a \"master\" or conduit\n>> network device which has a number of queues as well. In one version of the\n>> hardware that I work with, we have up to 4 ports, each with 8 queues, and the\n>> master device has a total of 32 hardware queues, so a 1:1 mapping is easy. With\n>> another version of the hardware, same number of ports and queues, but only 16\n>> hardware queues, so only a 2:1 mapping is possible.\n>>\n>> In order for congestion information to work properly, I need to establish a\n>> mapping, preferably before transmission starts (but reconfiguration while\n>> interfaces are running would be possible too) between these stacked device's\n>> queue and the conduit interface's queue.\n>>\n>> Comments, flames, rotten tomatoes, anything!\n> \n> Right, i think i understand.\n> \n> This works just for traffic between the host and ports. The host can\n> set the egress queue. And i assume the queues are priorities, either\n> absolute or weighted round robin, etc.\n> \n> But this has no effect on traffic going from port to port. At some\n> point, i expect you will want to offload TC for that.\n\nYou are absolutely right, this patch series aims at having the host be\nable to steer traffic towards particular switch port egress queues which\nare configured with specific priorities. At the moment it really is\nmapping one priority value (in the 802.1p sense) to one queue number and\nlet the switch scheduler figure things out.\n\nWith this patch set you can now use the multiq filter of tc and do\nexactly what is documented under Documentation/networking/multiqueue.txt\nand get the desired matches to be steered towards the queue you defined.\n\n> \n> How will the two interact? Could the TC rules also act on traffic from\n> the host to a port? Would it be simpler in the long run to just\n> implement TC rules?\n\nI suppose that you could somehow use TC to influence how the traffic\nfrom host to CPU works, but without a \"CPU\" port representor the\nquestion is how do we get that done? If we used \"eth0\" we need to\ncallback into the switch driver for programming..\n\nRegarding the last patch in this series, what I would ideally to replace\nit with is something along the lines of:\n\ntc bind dev sw0p0 queue 0 dev eth0 queue 16\n\nI am not sure if this is an action, or a filter, or something else...","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"uEQ3dpbP\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xk5RG1crHz9sNr\n\tfor ;\n\tFri, 1 Sep 2017 14:11:54 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750910AbdIAELA (ORCPT );\n\tFri, 1 Sep 2017 00:11:00 -0400","from mail-oi0-f65.google.com ([209.85.218.65]:38254 \"EHLO\n\tmail-oi0-f65.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750753AbdIAEK7 (ORCPT\n\t); Fri, 1 Sep 2017 00:10:59 -0400","by mail-oi0-f65.google.com with SMTP id r203so1229764oih.5\n\tfor ; Thu, 31 Aug 2017 21:10:59 -0700 (PDT)","from ?IPv6:2001:470:d:73f:e9b5:7cf7:cab:2662?\n\t([2001:470:d:73f:e9b5:7cf7:cab:2662])\n\tby smtp.gmail.com with ESMTPSA id\n\to132sm1615693oig.26.2017.08.31.21.10.56\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 31 Aug 2017 21:10:57 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=B8iRk/T4Yd+j5V+x0GWL6/n9PmT/fSBiKNMfCC1yg/c=;\n\tb=uEQ3dpbP7qYQ25sIs3/OA8FMVt+Lmc5eC6la9n4a3ItDPQqrsVQg7z3zOSrwnNZ0gb\n\tyS9W7AwAKgls03Df1J0wbWVM+jOKfRYogN74zaI3JIJdJq6pwV/XP9WkOk7yjsVd4BaY\n\tynIL2swDiMOQ5Z64npBZ4dXR/ETcofk01r16xGwD0aloD6Xitdo00etgfFVMil1hZmQJ\n\tt08QFlZVtwRWh41K1ANh22eOAK0u+2/Ek/MZ6BysJhfiCxW8lxZkUhw9JDjKvEt2+C2S\n\t9yhKvCZo+wFnts+KPEdDV02E7/D8sLV2wFy01tPD3ABgecXEcECOZO/uwz4A5smSjxrQ\n\t4Bzg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=B8iRk/T4Yd+j5V+x0GWL6/n9PmT/fSBiKNMfCC1yg/c=;\n\tb=JQWD6oC4yTR2I0GrsyDo0vx7v5UnESMOIpfJ6F08cCb36D/RcvKjwfZTHjfbY+CPPj\n\tziMqttO1q28BgRO4lx2gZgBhaOXlJKhNenQgxXCWC2bKyhbkogs45R24Z+XcZaesGzs1\n\twgQi7YqvqwKe8vE2auAPtebIZfy6SSrfYc/p/Jd7l9B4xjhTiFWrioq7QSRXFX7rE1nS\n\tEDHMweEPyo5rkJCOWS7/+sP2rtq3rearVEdxDiCpRyGMHKUDJTmucS8X4fnsL/viNrO0\n\t3FTcoIVXbCpmrZ7Ct7Aaix87Msd+SUxT+eibRHz9584b+wRzWn47L1Qo2/QCV1X/0RgJ\n\taANA==","X-Gm-Message-State":"AHPjjUgyrU0bnxqhMe1Eq54ki4eXOBLByHP2E9neudhID3x9QSq+5Vhw\n\tJFfO3juh0Y/TZw==","X-Google-Smtp-Source":"ADKCNb4mYz601dNL2GWi7sDiYTEIW+9FTdz4Msop+TmDZ1U2+mY+fZ8MAVuMUBD+jmkCNVJLYyv9dA==","X-Received":"by 10.202.172.204 with SMTP id v195mr554058oie.115.1504239059033;\n\tThu, 31 Aug 2017 21:10:59 -0700 (PDT)","Subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","To":"Andrew Lunn , jiri@resnulli.us, jhs@mojatatu.com","Cc":"netdev@vger.kernel.org, davem@davemloft.net,\n\txiyou.wangcong@gmail.com, vivien.didelot@savoirfairelinux.com","References":"<1504138732-65383-1-git-send-email-f.fainelli@gmail.com>\n\t<20170901000502.GB28960@lunn.ch>","From":"Florian Fainelli ","Message-ID":"<7d738ef5-c312-e0b3-3605-1f31fa7dc019@gmail.com>","Date":"Thu, 31 Aug 2017 21:10:55 -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":"<20170901000502.GB28960@lunn.ch>","Content-Type":"text/plain; charset=windows-1252","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761682,"web_url":"http://patchwork.ozlabs.org/comment/1761682/","msgid":"<20170901132921.GV22289@lunn.ch>","list_archive_url":null,"date":"2017-09-01T13:29:21","subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"> I suppose that you could somehow use TC to influence how the traffic\n> from host to CPU works, but without a \"CPU\" port representor the\n> question is how do we get that done? If we used \"eth0\" we need to\n> callback into the switch driver for programming..\n\nWe need to compare how the different switches work with respect to\nQoS. Marvell switches do a lot of the classification on the ingress\nport where it determines what queue the frame should be placed in on\nthe egress port. The egress port then schedules its queues.\n\nThis does not map to TC too well.\n\n> Regarding the last patch in this series, what I would ideally to replace\n> it with is something along the lines of:\n> \n> tc bind dev sw0p0 queue 0 dev eth0 queue 16\n\nWhy do you need this? sw0p0 has 8 queues? So i assume you use TC on\nsw0p0 to place frames into these queues? The queue then gets passed\ntransparently down through the conduit interface and then used by the\ntagger. I don't see why you need eth0 here? We try our best to avoid\neth0 wherever possible, it causes confusion. So i would prefer not to\nhave to use eth0 with TC commands.\n\n Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkKt73q5Jz9t2x\n\tfor ;\n\tFri, 1 Sep 2017 23:32:31 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752300AbdIANc0 (ORCPT );\n\tFri, 1 Sep 2017 09:32:26 -0400","from vps0.lunn.ch ([178.209.37.122]:49318 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752391AbdIAN30 (ORCPT );\n\tFri, 1 Sep 2017 09:29:26 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dnm0f-0007Ck-VA; Fri, 01 Sep 2017 15:29:21 +0200"],"Date":"Fri, 1 Sep 2017 15:29:21 +0200","From":"Andrew Lunn ","To":"Florian Fainelli ","Cc":"jiri@resnulli.us, jhs@mojatatu.com, netdev@vger.kernel.org,\n\tdavem@davemloft.net, xiyou.wangcong@gmail.com,\n\tvivien.didelot@savoirfairelinux.com","Subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","Message-ID":"<20170901132921.GV22289@lunn.ch>","References":"<1504138732-65383-1-git-send-email-f.fainelli@gmail.com>\n\t<20170901000502.GB28960@lunn.ch>\n\t<7d738ef5-c312-e0b3-3605-1f31fa7dc019@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<7d738ef5-c312-e0b3-3605-1f31fa7dc019@gmail.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761816,"web_url":"http://patchwork.ozlabs.org/comment/1761816/","msgid":"","list_archive_url":null,"date":"2017-09-01T16:46:26","subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 09/01/2017 06:29 AM, Andrew Lunn wrote:\n>> I suppose that you could somehow use TC to influence how the traffic\n>> from host to CPU works, but without a \"CPU\" port representor the\n>> question is how do we get that done? If we used \"eth0\" we need to\n>> callback into the switch driver for programming..\n> \n> We need to compare how the different switches work with respect to\n> QoS. Marvell switches do a lot of the classification on the ingress\n> port where it determines what queue the frame should be placed in on\n> the egress port. The egress port then schedules its queues.\n> \n> This does not map to TC too well.\n> \n>> Regarding the last patch in this series, what I would ideally to replace\n>> it with is something along the lines of:\n>>\n>> tc bind dev sw0p0 queue 0 dev eth0 queue 16\n> \n> Why do you need this? sw0p0 has 8 queues? So i assume you use TC on\n> sw0p0 to place frames into these queues? The queue then gets passed\n> transparently down through the conduit interface and then used by the\n> tagger. I don't see why you need eth0 here? We try our best to avoid\n> eth0 wherever possible, it causes confusion. So i would prefer not to\n> have to use eth0 with TC commands.\n\nWell, if you read through patch 8 maybe this is explained. The dynamic\nqueue selection is working fine through the use of the DSA network\ndevice's queue being passed to the Broadcom tag. If there was just I\nwould agree with you, but here is the catch below.\n\nWe also have this unique (AFAICT) hardware feature called Advanced\nCongestion Buffering (ACB) where the CPU Ethernet MAC can receive\ncongestion information from the switch queues directly, but out of band\nfrom specifically added HW logic and signals. This is not using pause\nframes.\n\nThis is useful for instance when your CPU is linking at 1Gbits/sec (or\nmore) internally with the switch, but you have connected external hosts\nthat are only 10/100 capable. When you push 1Gbits/sec of traffic\ntowards such hosts, you would get severe packet loss, unless you have\npause frames enabled. The problem with Pause frames within the SF2\nswitch design is that they are not per-flow though, so you can't resolve\nfrom the pause frames which egress queue to backpressure. With ACB\nthough, you get end-to-end backpressure between say, Port 8 and Port 0.\nIn order for this to work though, you need the CPU MAC to be inspecting\nor rather receiving congestion notification from the switch port and\nqueues directly.\n\nThis is why I need to define a mapping between switch (port P,queue Q)\nand CPU MAC queues (Q'). In the first generation HW, we have up to 4\nports exposed, each with 8 queues, and we have 32 CPU queues, 1:1\nmapping is possible. On 2nd generation hardware, same number of ports\nand queues per port, but only 16 queues, so a 2:1 mapping is possible only.\n\nIf I do not establish the mapping, several problems can occur but the\nmost severe is that congestion notification logic gets its congestion\ninformation from the wrong port and queue, so it can be permanently\nbackpressuring the CPU queue based on e.g: a disabled port. This results\nin the transmit queue being disabled, and so you get the netdev watchdog\nto kick in and scream.\n\nAs you can see from the last patch, I used a notifier to receive\ninformation when DSA slave network devices are added, from which I\nextract their port number and set up an internal mapping to the CPU\nqueues, but this is creating a layering violation since I have now the\nCPU driver extracting DSA specific net_device information.\n\nThe idea behind exposing a command like the proposed \"tc bind\" is to let\nusers define the mapping as they see fit. 1:1 or 2:1 mapping is fine as\na default, but may not be satisfactory for some use cases.\n\nHope this helps understand the bigger picture ;)","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"EO9U7w+p\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkQB94qFxz9t3F\n\tfor ;\n\tSat, 2 Sep 2017 02:46:41 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752151AbdIAQqj (ORCPT );\n\tFri, 1 Sep 2017 12:46:39 -0400","from mail-wr0-f172.google.com ([209.85.128.172]:34849 \"EHLO\n\tmail-wr0-f172.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751863AbdIAQqh (ORCPT\n\t); Fri, 1 Sep 2017 12:46:37 -0400","by mail-wr0-f172.google.com with SMTP id y15so1955958wrc.2\n\tfor ; Fri, 01 Sep 2017 09:46:37 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\t73sm227406wrl.56.2017.09.01.09.46.33\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 01 Sep 2017 09:46:35 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=HPj97NRx3z1+RAoY92maE1eIMwbqJJKqWwvfVOznT0Y=;\n\tb=EO9U7w+pILbxJF+gMXJeEOxFTYGkJ6xiNniL24U36tuE6Z5wS2+yJiCl3F/GLEMZgv\n\tfy7llRAPFsZxdcx5dySVmeRfL3rkg05EExsWgRHOYhaU+O7hmOCiwv7TVUj8lB1EZRrU\n\tdLukR6V64ZuAzVhmHJ8rz03XgtbkjgJIaFFziKLUWlrsEf+1ZkKa1zo8vlPWVRRLt1HA\n\tGp+RcgOIUxGE2dPY9t5hhhkPG4RKeGF6EWqsfGnR5qdn+d/uooLUD9i6qT9KEMwAtprJ\n\t0909zHYsD4KOleywApMhLw1LaO6nEo0VH1sQM5y/QVeBFgBSjtmSE3aagzLvnSjuLtud\n\tRvcw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=HPj97NRx3z1+RAoY92maE1eIMwbqJJKqWwvfVOznT0Y=;\n\tb=J5Z+4eWSIm0oY3ZbrAmkPHHLQ8Jc8DP3CaaabV9JNfqG2Tsj5bBKMBXZAC/gnnO9sx\n\tJrBGU98/BlSnCthucCzp0CoOJ6+bhS/4Sms2bkhKhj81i3niJukMA7XvOXff7O217MIK\n\tMYYLljdff/Rxx5uu+MMbzg8JR3AIb3gkFmKMKYDLOoGQJOW0sne7R5JUeDVDjkXN+nQf\n\tY5518drdORiEsgj5JRjlO6ACmwQ62rNHwVRHWgodB7kbS1M2QcLllXp6e+dC17o3SRCE\n\txWBiKPLbzMiOstVU5qqll/CugdN5RyZljMZs3jz29duog5BCb7vuaXQRzShEbuL1ZloR\n\t7Wng==","X-Gm-Message-State":"AHPjjUiL70isZ3b4bpMWn994C5uJqf4+nIQ/ucvEJNYm6EcNdaYqbkoZ\n\t1AIuMREiWIaRXg==","X-Google-Smtp-Source":"ADKCNb5g+mbOFxFr1kLFdZ+TAgC0P8wnMpQPrE1jN4aUOTipC4iwTkUBo6EOgCDT5VadNpjFZFzSNg==","X-Received":"by 10.223.141.210 with SMTP id o76mr905335wrb.254.1504284396430; \n\tFri, 01 Sep 2017 09:46:36 -0700 (PDT)","Subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","To":"Andrew Lunn , jiri@resnulli.us, jhs@mojatatu.com","Cc":"netdev@vger.kernel.org, davem@davemloft.net,\n\txiyou.wangcong@gmail.com, vivien.didelot@savoirfairelinux.com","References":"<1504138732-65383-1-git-send-email-f.fainelli@gmail.com>\n\t<20170901000502.GB28960@lunn.ch>\n\t<7d738ef5-c312-e0b3-3605-1f31fa7dc019@gmail.com>\n\t<20170901132921.GV22289@lunn.ch>","From":"Florian Fainelli ","Message-ID":"","Date":"Fri, 1 Sep 2017 09:46:26 -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":"<20170901132921.GV22289@lunn.ch>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761881,"web_url":"http://patchwork.ozlabs.org/comment/1761881/","msgid":"<20170901175529.GA1249@lunn.ch>","list_archive_url":null,"date":"2017-09-01T17:55:29","subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"Hi Florian\n\n> >> tc bind dev sw0p0 queue 0 dev eth0 queue 16\n\nIt this the eth0 i don't like here. Why not in the implementation just\nuse something like netdev_master_upper_dev_get('sw0p0')? Or does\n\ntc bind dev sw0p0 queue 0 dev lo queue 16\n\nmake sense?\n\n Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkRjj1K0Rz9t2x\n\tfor ;\n\tSat, 2 Sep 2017 03:55:37 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752213AbdIARze (ORCPT );\n\tFri, 1 Sep 2017 13:55:34 -0400","from vps0.lunn.ch ([178.209.37.122]:49937 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752143AbdIARzd (ORCPT );\n\tFri, 1 Sep 2017 13:55:33 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dnqAD-0001Zw-Qb; Fri, 01 Sep 2017 19:55:29 +0200"],"Date":"Fri, 1 Sep 2017 19:55:29 +0200","From":"Andrew Lunn ","To":"Florian Fainelli ","Cc":"jiri@resnulli.us, jhs@mojatatu.com, netdev@vger.kernel.org,\n\tdavem@davemloft.net, xiyou.wangcong@gmail.com,\n\tvivien.didelot@savoirfairelinux.com","Subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","Message-ID":"<20170901175529.GA1249@lunn.ch>","References":"<1504138732-65383-1-git-send-email-f.fainelli@gmail.com>\n\t<20170901000502.GB28960@lunn.ch>\n\t<7d738ef5-c312-e0b3-3605-1f31fa7dc019@gmail.com>\n\t<20170901132921.GV22289@lunn.ch>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761902,"web_url":"http://patchwork.ozlabs.org/comment/1761902/","msgid":"","list_archive_url":null,"date":"2017-09-01T18:27:43","subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 09/01/2017 10:55 AM, Andrew Lunn wrote:\n> Hi Florian\n> \n>>>> tc bind dev sw0p0 queue 0 dev eth0 queue 16\n> \n> It this the eth0 i don't like here. Why not in the implementation just\n> use something like netdev_master_upper_dev_get('sw0p0')? Or does\n> \n> tc bind dev sw0p0 queue 0 dev lo queue 16\n> \n> make sense?\n\nLast I brought this up with Jiri that we should link DSA network devices\nto their master network deviecs with netdev_upper_dev_link() he said\nthis was not appropriate for DSA slave network devices, but I can't\nremember why, I would assume that any stacked device set up would do that.\n\nIn any case, we need to establish a mapping so we have to specify at\nleast the target device's queue number. It is quite similar in premise\nto e.g: enslaving a network device to a bridge port:\n\nip link set dev eth0 master br0\n\nThanks","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"cA/Nj5K7\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkSR31h49z9sPk\n\tfor ;\n\tSat, 2 Sep 2017 04:27:59 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752363AbdIAS15 (ORCPT );\n\tFri, 1 Sep 2017 14:27:57 -0400","from mail-wr0-f172.google.com ([209.85.128.172]:35636 \"EHLO\n\tmail-wr0-f172.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752170AbdIAS14 (ORCPT\n\t); Fri, 1 Sep 2017 14:27:56 -0400","by mail-wr0-f172.google.com with SMTP id y15so2493468wrc.2\n\tfor ; Fri, 01 Sep 2017 11:27:55 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\tz136sm379928wmc.36.2017.09.01.11.27.45\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 01 Sep 2017 11:27:52 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=rFCo14GqbvTWwHeH7Bmd/DdLRokTmLjpQotE4RexS6c=;\n\tb=cA/Nj5K7Ut2MMt2AZBppptIH3MjTnCSlrq8oxg2X2p3tx+54eAoJpkVcmptFJa0Vv8\n\tLf5Xv+yh77YlU94prAsMTtWs+UHAdV7E6uotAENZAn7yoixPmutpT/Ef0T+nuPqpg4Id\n\tqowoU3shiYD73F7a/rJgM2SW8imb2J45vUJQJLrqTPT7oU51N1fIy/hhxBNh5+6lnrlW\n\tAlYyPF9dRzgR7tzfO4zAFwRX5Ui6stgznqbpYdRy1rvu+NFa5ub6z9bkaeuYCcLW1IDZ\n\t8h5ZiAtR+DbVnNONT37DK2h/xItu3GNANozKGTe2abuSAg4rqv6qmLjeJ9oMZXP6Vf6R\n\tpFsg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=rFCo14GqbvTWwHeH7Bmd/DdLRokTmLjpQotE4RexS6c=;\n\tb=jgA7BywbH307obIoX3CM0ZzT2NAjXtEj6SyN18dlk2RqzDtMdqfvWdPGXYmQ+J3VNs\n\tBMMTx39bcUd/cF7QlzrVGWQwEHnBQZ3sEIdJCRCSc8vqvms1uSUxqKmbS7nGNGtyY8iv\n\tVpEsjZCwci0B0kbPb1lQnS1tup66dAWN/d2v5Xe67V5K+PZpFkPUOrJt1Nvi9VD7C8+Z\n\t7DCHRyPIMW7ofHHc5C2ACoe/dBZwuTsBEGOcu2ScBlpSt0WoNWZYe27v6ULlImqG6R5l\n\toYwf8tUPZSCie/xJlY4rPOaIy1Yr7LBwC9ngSiYAclPouYlNwRmAH0bc2GC8eDZ9VIwa\n\te7aQ==","X-Gm-Message-State":"AHPjjUi633Q5V/BbydJCJ+7XPUAVTpRZIhQmzseHHYm92O7IE7MlZenL\n\ttxFTSzfcotD0BG0q2gs=","X-Google-Smtp-Source":"ADKCNb4gp3KSZEXnZgge2b686ss/n8HMH9Ehn/R1OmVYqWEGYQsFwPO70uUV3orgTiE5NQ5UY6PYUg==","X-Received":"by 10.223.179.68 with SMTP id k4mr1573018wrd.322.1504290474891; \n\tFri, 01 Sep 2017 11:27:54 -0700 (PDT)","Subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","To":"Andrew Lunn , jiri@resnulli.us","Cc":"jhs@mojatatu.com, netdev@vger.kernel.org, davem@davemloft.net,\n\txiyou.wangcong@gmail.com, vivien.didelot@savoirfairelinux.com","References":"<1504138732-65383-1-git-send-email-f.fainelli@gmail.com>\n\t<20170901000502.GB28960@lunn.ch>\n\t<7d738ef5-c312-e0b3-3605-1f31fa7dc019@gmail.com>\n\t<20170901132921.GV22289@lunn.ch>\n\t\n\t<20170901175529.GA1249@lunn.ch>","From":"Florian Fainelli ","Message-ID":"","Date":"Fri, 1 Sep 2017 11:27:43 -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":"<20170901175529.GA1249@lunn.ch>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761915,"web_url":"http://patchwork.ozlabs.org/comment/1761915/","msgid":"<20170901185012.GA8122@lunn.ch>","list_archive_url":null,"date":"2017-09-01T18:50:12","subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"On Fri, Sep 01, 2017 at 11:27:43AM -0700, Florian Fainelli wrote:\n> On 09/01/2017 10:55 AM, Andrew Lunn wrote:\n> > Hi Florian\n> > \n> >>>> tc bind dev sw0p0 queue 0 dev eth0 queue 16\n> > \n> > It this the eth0 i don't like here. Why not in the implementation just\n> > use something like netdev_master_upper_dev_get('sw0p0')? Or does\n> \n> Last I brought this up with Jiri that we should link DSA network devices\n> to their master network deviecs with netdev_upper_dev_link() he said\n> this was not appropriate for DSA slave network devices, but I can't\n> remember why, I would assume that any stacked device set up would do that.\n\nThere is some form a linking going, our device names show that:\n\n9: lan5@eth1: mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000\n link/ether da:87:2a:03:cf:16 brd ff:ff:ff:ff:ff:ff\n\n> In any case, we need to establish a mapping so we have to specify at\n> least the target device's queue number. It is quite similar in premise\n> to e.g: enslaving a network device to a bridge port:\n> \n> ip link set dev eth0 master br0\n\nBut here br0 is absolutely required, we have to say which bridge the\nslave port should be a member of.\n\nBut what good is eth0 in\n\ntc bind dev sw0p0 queue 0 dev eth0 queue 16\n\nAs i said suggesting, you have to somehow verify that eth0 is the\nconduit interface sw0p0 is using. Which makes the parameter pointless.\nDetermine it from the sw0p0 somehow.\n\n\t Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkSwv3Dxhz9sPm\n\tfor ;\n\tSat, 2 Sep 2017 04:50:23 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752202AbdIASuR (ORCPT );\n\tFri, 1 Sep 2017 14:50:17 -0400","from vps0.lunn.ch ([178.209.37.122]:50132 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752118AbdIASuQ (ORCPT );\n\tFri, 1 Sep 2017 14:50:16 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dnr1A-0002BN-Ge; Fri, 01 Sep 2017 20:50:12 +0200"],"Date":"Fri, 1 Sep 2017 20:50:12 +0200","From":"Andrew Lunn ","To":"Florian Fainelli ","Cc":"jiri@resnulli.us, jhs@mojatatu.com, netdev@vger.kernel.org,\n\tdavem@davemloft.net, xiyou.wangcong@gmail.com,\n\tvivien.didelot@savoirfairelinux.com","Subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","Message-ID":"<20170901185012.GA8122@lunn.ch>","References":"<1504138732-65383-1-git-send-email-f.fainelli@gmail.com>\n\t<20170901000502.GB28960@lunn.ch>\n\t<7d738ef5-c312-e0b3-3605-1f31fa7dc019@gmail.com>\n\t<20170901132921.GV22289@lunn.ch>\n\t\n\t<20170901175529.GA1249@lunn.ch>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761937,"web_url":"http://patchwork.ozlabs.org/comment/1761937/","msgid":"<5a3fa91f-fb1f-e5ea-987d-973dee3bf8eb@gmail.com>","list_archive_url":null,"date":"2017-09-01T19:21:43","subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 09/01/2017 11:50 AM, Andrew Lunn wrote:\n> On Fri, Sep 01, 2017 at 11:27:43AM -0700, Florian Fainelli wrote:\n>> On 09/01/2017 10:55 AM, Andrew Lunn wrote:\n>>> Hi Florian\n>>>\n>>>>>> tc bind dev sw0p0 queue 0 dev eth0 queue 16\n>>>\n>>> It this the eth0 i don't like here. Why not in the implementation just\n>>> use something like netdev_master_upper_dev_get('sw0p0')? Or does\n>>\n>> Last I brought this up with Jiri that we should link DSA network devices\n>> to their master network deviecs with netdev_upper_dev_link() he said\n>> this was not appropriate for DSA slave network devices, but I can't\n>> remember why, I would assume that any stacked device set up would do that.\n> \n> There is some form a linking going, our device names show that:\n> \n> 9: lan5@eth1: mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000\n> link/ether da:87:2a:03:cf:16 brd ff:ff:ff:ff:ff:ff\n\nThis is because iproute2 is linking the devices based on what\nndo_get_iflink() returns.\n\n> \n>> In any case, we need to establish a mapping so we have to specify at\n>> least the target device's queue number. It is quite similar in premise\n>> to e.g: enslaving a network device to a bridge port:\n>>\n>> ip link set dev eth0 master br0\n> \n> But here br0 is absolutely required, we have to say which bridge the\n> slave port should be a member of.\n\nRight,\n\n> \n> But what good is eth0 in\n> \n> tc bind dev sw0p0 queue 0 dev eth0 queue 16\n> \n> As i said suggesting, you have to somehow verify that eth0 is the\n> conduit interface sw0p0 is using. Which makes the parameter pointless.\n> Determine it from the sw0p0 somehow.\n\nI see what you mean, so something along the lines of just:\n\ntc bind dev swp0p0 queue 0 master queue 16\n\nwithout having to specify the master network device since it's implicit,\nI kind of like that.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"WlNeg25R\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkTdL35CNz9sQl\n\tfor ;\n\tSat, 2 Sep 2017 05:21:58 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752179AbdIATV4 (ORCPT );\n\tFri, 1 Sep 2017 15:21:56 -0400","from mail-wr0-f194.google.com ([209.85.128.194]:35431 \"EHLO\n\tmail-wr0-f194.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752095AbdIATVz (ORCPT\n\t); Fri, 1 Sep 2017 15:21:55 -0400","by mail-wr0-f194.google.com with SMTP id a47so514553wra.2\n\tfor ; Fri, 01 Sep 2017 12:21:54 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\tl80sm893652wrc.8.2017.09.01.12.21.46\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 01 Sep 2017 12:21:52 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=vYpuPNaTqZ951nnBzkntDyL2cSkQzX+z+UOsCxZZILY=;\n\tb=WlNeg25RBVsdYJzYtFXTSfo/KwjI0JFSU6vJnq7QlcX57WJ+FwnmJK562t/FCo6wFd\n\tWHMAPyENdP+oVsybHQF+4WUSHIMNavFh17MTU9z8dljlOYfozGed9o0FmUa/HVNeDnME\n\tDAPagnfs9Vt09+R//C2Z6NYF9S0eH4dx/GmrGUOAu05n9psXGD6TmQ5c5AqcTITv1nxT\n\tr9d82MdBDpD3Ec6LRm9j1mHNmHN8dsW/I8mY9hlOYTbusmvkY3AxjG+UQyMAFJt/WAET\n\tQOpiU6HZZDhw8jistw89WqP71rxjGU9TDpeTd1UNb8J2aBfmGMenWyroBvlqWTJRDls2\n\tnKJQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=vYpuPNaTqZ951nnBzkntDyL2cSkQzX+z+UOsCxZZILY=;\n\tb=K+fjdu/X8LnUcLIXlrjfbON1WdPfJwgNOiXqIReu5Tj4h/HYoAfnTLkKSw+2gbvv2W\n\toa82Ohrdc1iVqmNWjisAJ0u0bXug6Yiw/6txGKZiXbVPI6B8hyZ7zxS1TFqWnoPU/RaH\n\tg5+O0/3hlZPjE9yw9yX/VL+s9LhgTjks1uNsa1BlB2k2H1i+EucYALuijlkfHejuGOgv\n\tNhqP9w9k3AXnvn/X3cgEdSx7g1tIaAr5AN16nuVLqVUuHuIchEQe25N+pBPCEheep+sZ\n\tBZq11JrAxq5Zrb45PTHpz68AYsTHGZAoAaPjcn1yJ5XTrWlhFv7GWqT1rsOO8qw2rNOa\n\tCAcg==","X-Gm-Message-State":"AHPjjUiKgJK69yHRbDWLZOm3n3FHL5TKDAWnLwApsN/qob+xY7zDTHkK\n\tYxLbbFtiHD0e7Q==","X-Google-Smtp-Source":"ADKCNb6esXkeDrFil+JsYnJWptsxTGhtqRvcvS6scZtvtOftWaxgNqoadKMuB8T/7Odub1/J/vL6Jg==","X-Received":"by 10.223.158.146 with SMTP id a18mr1704832wrf.311.1504293713904;\n\tFri, 01 Sep 2017 12:21:53 -0700 (PDT)","Subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","To":"Andrew Lunn ","Cc":"jiri@resnulli.us, jhs@mojatatu.com, netdev@vger.kernel.org,\n\tdavem@davemloft.net, xiyou.wangcong@gmail.com,\n\tvivien.didelot@savoirfairelinux.com","References":"<1504138732-65383-1-git-send-email-f.fainelli@gmail.com>\n\t<20170901000502.GB28960@lunn.ch>\n\t<7d738ef5-c312-e0b3-3605-1f31fa7dc019@gmail.com>\n\t<20170901132921.GV22289@lunn.ch>\n\t\n\t<20170901175529.GA1249@lunn.ch>\n\t\n\t<20170901185012.GA8122@lunn.ch>","From":"Florian Fainelli ","Message-ID":"<5a3fa91f-fb1f-e5ea-987d-973dee3bf8eb@gmail.com>","Date":"Fri, 1 Sep 2017 12:21:43 -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":"<20170901185012.GA8122@lunn.ch>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761949,"web_url":"http://patchwork.ozlabs.org/comment/1761949/","msgid":"<20170901194429.GB8122@lunn.ch>","list_archive_url":null,"date":"2017-09-01T19:44:29","subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"> I see what you mean, so something along the lines of just:\n> \n> tc bind dev swp0p0 queue 0 master queue 16\n> \n> without having to specify the master network device since it's implicit,\n> I kind of like that.\n\nYes, that is better.\n\n Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkV7T20HYz9sPt\n\tfor ;\n\tSat, 2 Sep 2017 05:44:37 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752526AbdIAToe (ORCPT );\n\tFri, 1 Sep 2017 15:44:34 -0400","from vps0.lunn.ch ([178.209.37.122]:50185 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752485AbdIATod (ORCPT );\n\tFri, 1 Sep 2017 15:44:33 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dnrrh-0002bw-E9; Fri, 01 Sep 2017 21:44:29 +0200"],"Date":"Fri, 1 Sep 2017 21:44:29 +0200","From":"Andrew Lunn ","To":"Florian Fainelli ","Cc":"jiri@resnulli.us, jhs@mojatatu.com, netdev@vger.kernel.org,\n\tdavem@davemloft.net, xiyou.wangcong@gmail.com,\n\tvivien.didelot@savoirfairelinux.com","Subject":"Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness","Message-ID":"<20170901194429.GB8122@lunn.ch>","References":"<1504138732-65383-1-git-send-email-f.fainelli@gmail.com>\n\t<20170901000502.GB28960@lunn.ch>\n\t<7d738ef5-c312-e0b3-3605-1f31fa7dc019@gmail.com>\n\t<20170901132921.GV22289@lunn.ch>\n\t\n\t<20170901175529.GA1249@lunn.ch>\n\t\n\t<20170901185012.GA8122@lunn.ch>\n\t<5a3fa91f-fb1f-e5ea-987d-973dee3bf8eb@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<5a3fa91f-fb1f-e5ea-987d-973dee3bf8eb@gmail.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]