On 12/13/2016 12:49 PM, Joao Pinto wrote: > Hi Niklas, > > Às 4:25 PM de 12/12/2016, Niklas Cassel escreveu: >> >> On 12/12/2016 11:19 AM, Joao Pinto wrote: >>> Hi, >>> >>> Às 1:44 AM de 12/10/2016, Florian Fainelli escreveu: >>>> Le 12/09/16 à 16:16, Andy Shevchenko a écrit : >>>>> On Sat, Dec 10, 2016 at 12:52 AM, Florian Fainelli <f.faine...@gmail.com> >>>>> wrote: > (snip...) > > >>> @Rabin Vincent: Hi Rabin. Since Axis is more familiar with the >>> synopsys/*qos* >>> driver would it be possible for you to make an initial analysis of what has >>> to >>> be merged into Stmmac? This way the development would speed-up. >> I can answer that question. >> >> I've sent out 12 patches to the stmmac driver >> (all patches are included in the current net-next tree), >> with these patches the stmmac driver works properly on Axis hardware >> (we use Synopsys GMAC 4.10a synthesized with multiple TX queues). >> stmmac's DT binding has also been extended with properties that >> existed in DWC EQoS's DT binding, such as no-pbl-x8, txpbl, rxpbl. >> >> Since we have no problem updating the DTB together with the kernel, >> we will simply move to using the start using the stmmac driver, >> with stmmac's DT binding. >> >> However, I've noticed that NVIDIA has extended the DWC EQoS DT binding, >> I don't how easy it would be for them to switch to stmmac's DT binding. >> (Adding Stephen Warren to CC.) >> >> The reset sequence that Lars Persson was worried about is not an issue >> with the stmmac driver. > Great! So you saying that stmmac works great with AXIS hardware and no need to > merge specific code from AXIS' *qos* driver?
Yes. From Axis point of view, we are done. stmmac works and we will move to that driver + DT binding. However, it seems like Stephen Warren will NAK if you try to remove synopsys/dwc_eth_qos.c before Documentation/devicetree/bindings/net/stmmac.txt is compatible with Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt You might want to sync with him. I have no idea, but perhaps they are only using a subset of all the available properties. Perhaps, only implementing what they are using might be enough, I don't know. I couldn't find their DTS in arch/arm/dts. I guess you might want to know David Miller's opinion, since he's the one who decides in the end. >> >> >> >> There are some performance problems with the stmmac driver though: >> >> When running iperf3 with 3 streams: >> iperf3 -c 192.168.0.90 -P 3 -t 30 >> iperf3 -c 192.168.0.90 -P 3 -t 30 -R >> >> I get really bad fairness between the streams. >> >> This appears to be an issue with how TX IRQ coalescing is implemented in >> stmmac. >> Disabling TX IRQ coalescing in the stmmac driver makes the problem go away. >> We have a local patch that implements TX IRQ coalescing in the dwceqos >> driver, >> and we don't see the same problem. >> >> Also netperf TCP_RR and UDP_RR gives really bad results compared to the >> dwceqos driver (without IRQ coalescing). >> 2000 transactions/sec vs 9000 transactions/sec. >> Turning TX IRQ coalescing off and RX interrupt watchdog off in stmmac >> gives the same performance. I guess it's a trade off, low CPU usage >> vs low latency, so I don't know how important TCP_RR/UDP_RR really is. >> >> The best thing would be to get a good working TX IRQ coalesce >> implementation with HR timers in stmmac. >> Perhaps it should also be investigated if the RX interrupt watchdog >> timeout should have a lower default value. >> >> >> >>> Thanks to all. >>> >>> Joao
