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

[Petr Cvek]

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").

> 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.

>> 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.

>> 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