You’ll probably struggle with the patch if you’re not familiar. I’ll try to port the patch over to my openwrt-19.07 branch when I’m done with the cryptoapi driver. Think I’m close to making it work with multi scatterlist segments.

do you think perf will be acceptable ?
Anyway do you had this by any chance ?

wlan0: NSS TX failed with error[8]: NSS_TX_FAILURE_NOT_ENABLED

Change your NSS core clock to 800Mhz.

Edit: as for the performance of the cryptoapi driver, I think it’ll be worst off compared to software. But I’m more interested to make it work for now and see how to improve it if possible.

Yes, I need someone like you give me some tips
Thank you very much

I managed to set ap_isolate=0 in the hostapd-phy[x].conf. Unfortunately, that did not solve the wifi pinging problem.

@Ansuel, I got the multi segment patch done and did some benchmark. As expected, performance is worst compared to software. Small payload performance is very much worst compared to larger payloads. The only consolation would be that the Krait CPU utilisation is low when ciphering is performed.

Results as shown below:

With NSS crypto engine:

cmd: openssl speed -multi <#> -elapsed -evp aes-128-cbc
          type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
multi 1 - evp                 57.71k      228.33k      901.21k     3721.22k    25534.46k    42172.42k
multi 2 - evp                115.31k      474.11k     1788.84k     7097.69k    48073.39k    82209.45k
multi 4 - evp                213.83k      804.63k     3343.10k    13139.97k    87851.01k   154785.11k
multi 8 - evp                372.37k     1520.49k     5923.13k    24416.26k   163594.24k   279426.14k

With software based crypto engine:

cmd: openssl speed -multi <#> -elapsed aes-128-cbc
          type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
multi 1 - aes-128 cbc      67744.05k    76908.97k    80787.80k    81865.39k    81619.63k    81324.71k
multi 2 - aes-128 cbc     126358.25k   146981.03k   153913.83k   156381.53k   155462.31k   153796.61k
multi 4 - aes-128 cbc     115177.91k   146950.73k   154273.49k   155684.82k   155689.95k   156975.10k
multi 8 - aes-128 cbc     114552.63k   146711.88k   153911.55k   155999.50k   156242.05k   156512.62k

As expected with 2 or more threads, software based crypto hit the throughput ceiling with the 2 CPU cores both at 100% throughout the benchmark.

Couldn't go to 16 threads as the NSS crypto driver complains about not able to allocate crypto sessions.

@drbrains the results looks comparable to the eip-93 engine you've developed for the mt7621a SoC for 1 thread, but the beefier ipq806x SoC moves ahead with 4 crypto engines when benched with multiple threads. I read the performance benchmark doc you pushed into your Github repo. Have you made any progress in improving the performance of the eip-93 driver? I could learn from your approach if you made a breakthrough.

1 Like

@quarky
Could you make "shortcut-fe: rework netfilter conntrack notification" for 4.4 kernel too later,if it's convenient to you ,I would try build lede-17.01-ipq806x-nss also
thanks

Why would you want to go back to 4.4? Wouldn't it be better to go straight to master on 5.4 instead? 4.4 patches will stop soon IIRC.

I'm very interesting on your fastpatch,it's real good for my router :smiley:

@robimarko @Ansuel, this patch allows ipq806x boards to use initramfs to boot master 5.4 kernel with the pcie bus totally functional. Wi-Fi interfaces is up with this patch when my R7800 boots with initramfs. So it looks like bootipq just resets the pcie bus. I have no idea where in the kernel codes the reset is done tho, as when I tried to scan the 'driver/pci' directory for the 'reset-gpios' string, it came up empty, at least for the driver files used by the ipq806x SoC. Most likely done by the GPIO drivers.

Which router(s) are you building for?

For ipq806x , R7800,EA7500V1
For ath79 netgear4500v3
For ar71xx TL-WR810N v1

I've pushed the shortcut-fe changes that reworked the ct notifier APIs. You can get to the changes here:

kernel 4.4 - lede-17.01-ipq806x-nss
kernel 4.14 - openwrt-19.07-ipq806x-nss
kernel 5.4 - master-ipq806x-nss-qsdk11

Hope I didn't miss out anything and it works for you.

@quarky
Cool!
Your help are very much appreciated
if you want,I would buy a beer for you later :beers:

I’m glad my work is being used by others. No worries.

Hm, maybe its only the polarity of the resets being wrongly set in the DTSI?
Because PCI driver needs to reset the thing anyway

I suppose. Anyway, it’s working for me now, so I can continue my tests with initramfs image. That’ll save a lot of wear on the NAND flash.

Great to know, If I have some time I will dig into whats actually happening.

NAND-s are designed to have huge amounts of R/W.
I have a IPQ40xx device with a SPI-NAND for testing that has over 500 full formats and rewrites on it and still no issues.

1 Like

I still can't seem to compile: master-ipq806x-nss-qsdk11
Errors with ncurses

Could be due to your build environment. Are you able to build an image straight from openwrt/master?

In any case if you don’t have the QSDK 11 NSS firmware binaries, there’s no point building from my Github source branch. It will not work without the binaries.