lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 10 May 2017 02:42:21 +0000 From: Andy Duan <fugang.duan@....com> To: David Miller <davem@...emloft.net>, "stefan@...er.ch" <stefan@...er.ch> CC: "andrew@...n.ch" <andrew@...n.ch>, "festevam@...il.com" <festevam@...il.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: RE: [PATCH] net: fec: select queue depending on VLAN priority From: David Miller <davem@...emloft.net> Sent: Tuesday, May 09, 2017 9:39 PM >To: stefan@...er.ch >Cc: Andy Duan <fugang.duan@....com>; andrew@...n.ch; >festevam@...il.com; netdev@...r.kernel.org; linux- >kernel@...r.kernel.org >Subject: Re: [PATCH] net: fec: select queue depending on VLAN priority > >From: Stefan Agner <stefan@...er.ch> >Date: Mon, 8 May 2017 22:37:08 -0700 > >> Since the addition of the multi queue code with commit 59d0f7465644 >> ("net: fec: init multi queue date structure") the queue selection has >> been handelt by the default transmit queue selection implementation >> which tries to evenly distribute the traffic across all available >> queues. This selection presumes that the queues are using an equal >> priority, however, the queues 1 and 2 are actually of higher priority >> (the classification of the queues is enabled in fec_enet_enable_ring). >> >> This can lead to net scheduler warnings and continuous TX ring dumps >> when exercising the system with iperf. >> >> Use only queue 0 for all common traffic (no VLAN and P802.1p priority >> 0 and 1) and route level 2-7 through queue 1 and 2. >> >> Signed-off-by: Fugang Duan <fugang.duan@....com> >> Fixes: 59d0f7465644 ("net: fec: init multi queue date structure") > >If the queues are used for prioritization, and it does not have multiple normal >priority level queues, multiqueue is not what the driver should have >implemented. Firstly, HW multiple queues support: - Traffic-shaping bandwidth distribution supports credit-based and round-robin-based policies. Either policy can be combined with time-based shaping. - AVB (Audio Video Bridging, IEEE 802.1Qav) features: * Credit-based bandwidth distribution policy can be combined with time-based shaping * AVB endpoint talker and listener support * Support for arbitration between different priority traffic (for example, AVB class A, AVB class B, and non-AVB) Round-robin-based policies: It has the same priority for three queues: In the round-robin QoS scheme, each queue is given an equal opportunity to transmit one frame. For example, if queue n has a frame to transmit, the queue transmits its frame. After queue n has transmitted its frame, or if queue n does not have a frame to transmit, queue n+1 is then allowed to transmit its frame, and so on. Credit-based policies: The AVB credit based shaper acts independently, per class, to control the bandwidth distribution between normal traffic and time-sensitive traffic with respect to the total link bandwidth available. Credit based shaper conbined with time-based shaping: - priority: ClassA queue > ClassB queue > best effort - ensure the queue bandwidth as user set based on time-based shaping algorithms (transmitter transmit frame from three queue in turn based on time-based shaping algorithms) And in real AVB case, each streaming can be independent, and are fixed on related queue. Then driver level should implement .ndo_select_queue() to put the streaming into related queue. That is what the patch did. The current driver config the three queue to credit-based policies (AVB), the patch seems no problem for the implementation. Do you have any suggestion ? Andy
Powered by blists - more mailing lists