Just like netgear r9000 / xr700 ?
While the r9000/ xr700 is very capable hardware, it is not supported by OpenWrt, yet (yes, I'm aware of Netgear X10 (R9000), but there is a quite major difference between support being formally merged and a private fork, even if the later is kept up to date) - nor does it look likely that it will be.
In terms of routing performance, the r9000 probably wins (ipq807x just completely relies on NSS offloading, with rather much left to be desired in the ethernet/ switch drivers, while the AL-514 has more grunt power - but there's zero mainline support for it and the company no longer exists (bought by Amazon and concentrating on in-house designs)) - on the wireless side, the rt-ax89x is a clear winner (and ARMv8 is also an advantage looking into the future).
1 Like
Yes but since nss won't be included in official openwrt is useless for most of us... Then no 6GHz radio is also not so much of use. Also as it came to wifi 7 router based on qualcom there will be same situation... Cripled by qualcom support.
I wouldn't go that far, but yes, 10 GBit/s throughput isn't achievable without NSS or quite significant (non-NSS) improvements on the ethernet/ switch drivers.
Not in this device, but there are other (not-yet-supported-but-supportable) ipq807x devices with 6 GHz radios. But to be fair, neither does the r9000 have 6 GHz support (yes, it has 802.11ad/ 60 GHz, which is much less useful in terms of client support and range).
We'll have to wait and see (yes, the specs suggest that IPQ951x/ IPQ955x/ IPQ957x will still come with NSS cores, but they'll also upgrade to quad cortex A73; yes, ath12k seems to be a copycat of ath11k, …).
Just saying that the r9000 shouldn't really be regarded as an alternative to ipq807x/ ipq957x - as its OpenWrt status is non-existent and its wireless side getting dated (802.11ax roughly doubles the throughput in practice, relative to 802.11ac).
I saw that IEI PUZZLE-M902 with 4-core ARM A72 seems to be able to handle 10G as well, does that platform having some kind of hardware acceleration included?
Nope, it just has a proper ethernet driver that has basic offloading.
Sadly, there are no docs for EDMAv1 that is used in IPQ807x/60xx/50xx and it lacks any kind of offloading, not even checksum is offloaded.
QCA pretty much only improves EDMA v2 as IPQ957x and IPQ533x series dont have NSS cores and they just use NSS on older platforms to offload everything and achieve the throughput.
Just basic offloading would drastically improve the performance but poking around the descriptor bits led me nowhere.
1 Like
@a_guy Sorry to bother you, but this thing is first board I have with SFP and its rather not intuitive how to wire it.
OEM DTS claims there is a PHY at 0x1e for SFP but I just dont see anything there, but I wired up DTS:
port@4 {
port_id = <5>;
phy_address = <30>;
phy_i2c_address = <30>;
phy-i2c-mode; /*i2c access phy */
media-type = "sfp"; /* fiber mode */
};
However, SSDK is constantly trying to use port 0x20 for whatever reason.
[ 1.814820] sfp_phy_init[229]:INFO:sfp phy init for port 0x20!
[ 1.823988] sfp_phy_probe[68]:INFO:sfp phy is probed!
Something is missing as even after wiring up I2C its not printing the SFP module info like in stock FW.
How did you wire it up to NSS-DP?
Ok, so just removing the phandle to PHY seems to kind of work but not properly.
It loops through all switch_lan_bmp ports. That's why it prints 20 for port 5
Yes, that exactly what I did. If you find a better way - let me know and I correct my DTS as well
Same story here: sfp is not showing up on mdio
It seems we will need to fallback to connecting the PHY by manually generating the name like NSS-DP used to do for the SFP as SSDK is manually registering the SFP PHY driver and then the SFP PHY and it lacks any kind of OF node to use for it.
Another option would be to add some kind of a compatible to search in SSDK and use that node during PHY registration.
Understood, but it kinda 'works' now and this replicates what OEM does, right? What will it give us if we do wire it fully? Ethtool will work? Would we be able to control link rate, etc?
I also tried 'xaaaabbbbb' compatible - crashed for me
Do you mean the AQC113 10G NIC of IEI M902?
Yeah, trying to register it by using the compatible will make it crash.
OEMs do all kinds of crap, including completely bypassing the kernel when it comes to SFP support and doing this dance with registering a fake PHY for it so it can adjust the MAC link based on the SFP.
QCA/OEM do register the SFP PHY with appropriate NSS DP node as otherwise it has no idea about the link state.
SSDK is not parsing/printing the SFP EEPROM as well currently.
Yeah, even the SoC ethernet controller has basic offloading.
Well, this would need to rollback/fix that patch I was talking about? It drops old mechanisms to connect to PHY and new one doesn't work as there is no of_node for sfp?
Yeah, partially but I am going to rather try attaching an OF node to the PHY SSDK registers than using that manual name string generation and matching that QCA uses
1 Like
OK I just look at my Buffalo WXR-5950AX12, which is IPQ8074A + AQC107, so from what you mentioned above, is one of the 10G interfaces IPQ8074A cannot do hardware offload without NSS, right? (Since the AQC107 shouldn't be a problem)
I doubt its AQC107, its probably just AQR107 which is just a 10G PHY and not a NIC
That's was my initial attempt too but it became a rabbit hole as I don't have enough understanding of both Linux PHY subsystem and ssdk 
1 Like