[LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621

[John Crispin]

On 20/08/17 01:13, Florian Fainelli wrote:
>
> On 08/19/2017 03:30 PM, John Crispin wrote:
>>
>> On 20/08/17 00:07, Kristian Evensen wrote:
>>> On Sat, 19 Aug 2017 at 23:52, John Crispin <john at phrozen.org
>>> <mailto:john at phrozen.org>> wrote:
>>>
>>>
>>>
>>>      On 19/08/17 23:13, Kristian Evensen wrote:
>>>      > Hi both,
>>>      >
>>>      > On Sat, 19 Aug 2017 at 20:16, John Crispin <john at phrozen.org
>>>      <mailto:john at phrozen.org>
>>>      > <mailto:john at phrozen.org <mailto:john at phrozen.org>>> wrote:
>>>      >
>>>      >     Hi All,
>>>      >
>>>      >     i have a staged commit on my laptop that makes all the
>>>      (upstream)
>>>      >     ethernet fixes that i pushed to mt7623 work on mt7621.
>>>      please hang on
>>>      >     for a few more days till i finished testing the support.
>>>      this will add
>>>      >     latest upstream ethernet support + DSA
>>>      >
>>>      >
>>>      > Thanks for the follow-up Mingyu and the info John. I have not
>>>      had time
>>>      > to investigate the issue further (holiday backlog ...), but will
>>>      start
>>>      > working on trying to reproduce it at the end of next week. I have
>>>      > deployed the patch to some routers and have not seen any
>>>      regressions,
>>>      > but I would like to know how to reliably trigger the issue before
>>>      > concluding :)
>>>      >
>>>      > John, does your commits include a fix similar to what Mingyu
>>>      sent me?
>>>
>>>
>>>      with my fixes the mt7623 passes a 48h stress test running the unit
>>>      on a
>>>      iperf test with 200 parallel flows at full wire speed. once
>>> backported
>>>      to mt7621 i am pretty confident that the fix will yield the maximum
>>>      stable performance we can get.
>>>
>>>
>>> Thanks! I will focus on finding a way to reproduce the issue then, and
>>> then test Mingyu and your patches. Out of curiosity, when you say
>>> maximum stable performance, does that mean that the hwnat will also be
>>> backported?
>>>
>>> Kristian
>>>
>> correct, in my testing i have been ... with 200 parallel flows ... on
>> MT7623, we'll have to find out what mt7621 can achieve ... this is all
>> using hwnat ...
>> 1) tcp - at 50 byte frames i am able to pass 720 MBit which is > 1M FPS
>> 2) udp - at 128 byte frames i am able to pass ~450k FPS at ~10% packet
>> loss .. at near wirespeed
>>
>> in a nutshell ... UDP has no TC. due to this, the lower the frame size,
>> the higher the packet loss. the HW NAT will assert the FC bit inside the
>> GMAC. when using TCP this will cause back pressure to make the OS stall
>> the connection and reduce max throughput. in contrast, when using UDP
>> you'll see packet loss go up instead of dropping throughput as there is
>> no TC.
>>
>> also i have managed to make HW QoS work, still working on the best way
>> to integrate this with fw3. HW QoS doe perform remarkably well on
>> mt7623. when saturating the link doing lan->wan traffic i am able to ssh
>> into the unit and only have a slight subjective increase in latency.
> Nice, do you think this could be interfaced with the TC offloads that
> the newer kernels support? What kind of HW QoS can you configure on MT7623?
Hi Florian,

there are 2 tasks

1) once pablo finished his flow table offloading i will invest private 
resources to get HW NAT code for QCA8k and mt7530 upstreamed. i spoke 
with pablo and my current understanding is that his patches will 
accommodate both silicons. once his patches are public we'll know more ...
2) figure out how to get HW QoS upstream ... on mediatek i have fully 
rev'ed the silicon and already looked at TC integration and believe we 
can make it work with those new patches. regarding qca8k i am not fully 
sure yet that this is possible due to how the silicon works .. might 
require some patching .. TBD

     John