[OpenWrt-Devel] [RFC] lantiq: SMP interrupts and ethernet driver backport from vanilla v5

[Hauke Mehrtens]

On 2/10/19 5:28 PM, Petr Cvek wrote:
> Hi,
> 
> Dne 10. 02. 19 v 16:49 Hauke Mehrtens napsal(a):
>> Hi Petr,
>>
>> Thank you for the tests.
>>
>> On 2/3/19 9:44 AM, Petr Cvek wrote:
>>> I did an exhaustive ethernet measuring. Parameters: no wifi, no running
>>> dsl connection, 1 cable (in 1G port with external phy), no USB, almost
>>> vanilla openwrt (changes for rootfs on NFS, kernel command line and fix
>>> for uwc2 USB).
>>>
>>> run.sh
>>> A script which runs and logs measurements into a file named by its first
>>> parameter (or just the unix epoch time). You need to run "iperf3 -s" on
>>> lantiq manually.
>>
>> I am surprised that "iperf3 -c 10.0.0.80" has the double speed of
>> "iperf3 -c 10.0.0.80 -R" isn't this the same stream just in the
>> different direction?
>>
> Yeah that's why I started poking in the system at the first place. The
> transmitting out was slow. It seems the problem is in the packet
> generation, probably copying a skb into a linear buffer. When I
> converted the driver for the skb frags support it speeded up (thread:
> "[OpenWrt-Devel] [RFC] [PATCH v2] lantiq: net: ethernet driver with
> fragments").

One of the iperf instances was running on the router?
When the VR9 SoC was doing the TX it was slow and when it received it
was fast.

There are also 2 areas for the DMA controller so we can remove the
locking in the dma controller and use one register area for each CPU.

Did you also test the forwarding performance like NAT between 2 pots?


>> In the SoC there are 2 internal GPHYs and some *MII connections to
>> external PHYs. They are all connected to the GSWIP inside of the SoC, on
>> the CPU port normally a special tag is added to every packet which
>> indicates from which LAN port it was received on. This CPU port is
>> connected to the PPE and the PPE is connected to two DMA channels which
>> send the packets to the MIPS CPU running Linux. There are two ports
>> between the PPA and the CPU, the upstream driver only uses one of these
>> ports as we let the PPE stay in the default configuration. We could
>> later use it to put high prio packets on a special channel or to put the
>> DSL packets onto the other channel.
>>
> 
> Or make something like dual queue which is in the lantiq etop driver?
> Thanks for info. I was thinking about a generic dual queue (each VPE
> handling one) could be another speedup.

Yes we can probably also do something like this.

> 
>>> 3) The second ICU devicetree node doesn't need to be deleted for
>>> uniprocessor ICU usage.
>>
>> When the Voice firmware is used the second VPE is used for this FW and
>> not for Linux then the ICU should only use one block.
>>
> So machines with voice ports won't have second ICU node and machines
> without voice ports can have it.

To make voice work you need the voice FW whihc runs on one VPE.

> 
>>> Feel free to make your own tests and sorry for hardcoded IPs :-D
>>
>> I would like to use the upstream driver also in OpenWrt, I am working on
>> bridge offloading for the upstream DSA driver.  OpenWrt still misses a
>> script which can convert the common swconfig configuration into a bridge
>> configuration if such a script would be there I would like to switch to
>> the DSA driver with kernel 4.19.
>> Therefore I am not sure how efficient it is to invest so much time into
>> the driver currently used in OpenWrt.
>>
> 
> Well my changes are mostly only in xmit and TX polling NAPI code, maybe
> some DMA intialization, so it should be fairly compatible I can patch
> it. We should definitely put skb frags code in the final version though.
> 
> Petr

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel