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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AM4PR0401MB2260F316B39A05C659EE1ECDFFEF0@AM4PR0401MB2260.eurprd04.prod.outlook.com>
Date:   Tue, 9 May 2017 10:35:18 +0000
From:   Andy Duan <fugang.duan@....com>
To:     Stefan Agner <stefan@...er.ch>, Andrew Lunn <andrew@...n.ch>
CC:     "festevam@...il.com" <festevam@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "netdev-owner@...r.kernel.org" <netdev-owner@...r.kernel.org>
Subject: RE: FEC on i.MX 7 transmit queue timeout

From: Stefan Agner <stefan@...er.ch> Sent: Tuesday, May 09, 2017 2:23 AM
>To: Andy Duan <fugang.duan@....com>; Andrew Lunn <andrew@...n.ch>
>Cc: festevam@...il.com; netdev@...r.kernel.org; netdev-
>owner@...r.kernel.org
>Subject: Re: FEC on i.MX 7 transmit queue timeout
>
>On 2017-05-07 19:13, Andy Duan wrote:
>> From: Andrew Lunn <andrew@...n.ch> Sent: Friday, May 05, 2017 8:24 PM
>>>To: Andy Duan <fugang.duan@....com>
>>>Cc: Stefan Agner <stefan@...er.ch>; festevam@...il.com;
>>>netdev@...r.kernel.org; netdev-owner@...r.kernel.org
>>>Subject: Re: FEC on i.MX 7 transmit queue timeout
>>>
>>>> No, it is not workaround. As i said, quque1 and queue2 are for AVB
>>>> paths have higher priority in transmition.
>>>
>>>Does this higher priority result in the low priority queue being
>>>starved? Is that why the timer goes off? What happens when somebody
>>>does use AVB. Are we back to the same problem? This is what seems to
>>>make is sounds like a work around, not a fix.
>>>
>>>     Andrew
>> Yes, queue0 may be blocked by queue1 and queue2, then the queue0
>> watchdog time maybe triggered.
>> If somebody use AVB quque1 and queue2, the remaining bandwidth is for
>> queue0, for example, in 100Mbps system, quque1 cost 50Mbps bandwidth
>> and queue2 cost 50Mbps bandwidth for audio and video streaming, then
>> queue0 (best effort) has 0 bandwidth that limit user case cannot have
>> asynchronous frames (IP(tcp/udp)) on networking. Of course these is
>> extreme case.
>> In essentially,  asynchronous frames (IP) go queue0 for the original
>> design. To do these just implement .ndo_select_queue() callback in
>> driver like fsl tree.
>
>I guess you refer to this commit?
>
>http://git.freescale.com/git/cgit.cgi/imx/linux-
>imx.git/commit/?h=imx_4.1.15_2.0.0_ga&id=b0d8fa989651baf847287f6888f4d
>7b723e2a207
>
>It seems that by default there is a Credit-based scheme enabled
>(ENETx_QOS[TX_SCHEME] = 000). The driver enables the queue1/2 and
>assigns it each 50% of the bandwidth (IDLE_SLOPE_1/2 is set to 0x200, which
>according to the register description of IDLE_SLOPE means BW fraction of 0.5!).
>This actually violates even the note in register
>ENETx_DMAnCFG:
>
>"NOTE: For AVB applications, the BW fraction of class 1 and class 2 combined
>must not exceed .75."
>
Yes, the suggested BW fraction for class1 and class2 must not exceed .75, otherwise best effort
Queue will be blocked then watchdog timeout on queue0.

How to set the BW fraction that is up to user case.

>Instead of using the credit based scheme we could switch to round robin, but
>not sure if that is what we want.
> 
Using round robin has no meaning for AVB feature.

>What is the default criteria to select queues when .ndo_select_queue is not
>provided? I guess it tries to balance individual streams/processes for better
>SMP performance?
>
Since AVB audio/video streaming is based on IEEE1722 format,  .ndo_select_queue just parse
the avb streaming and insect the skb into class1 and class2 queues, which are individual streaming and processes.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ