> Date: Mon, 20 Jul 2020 08:16:34 +0300 > From: Andrius V <[email protected]> > > Considering it is limited usage isn't the kernel module actually more > useful, since you can add it to boot config once you really need it? > Unless, in-kernel functionality won't work with the kernel module for some > reason. Regardless, I was simply looking from the perspective of i386, > since it has the module available, why not just to move config for both? I > can agree though, that probably there were close to zero users utilizing > padlock over the years. Nevertheless, I have two VIA Nano boards, both > successfully booted with a padlock engine attached.
The code is just not worth much, and I kind of plan to delete it altogether once a few other things in the kernel AES stack are fixed. If you're not doing in-kernel IPsec it's really not worth anything. > Unfortunately, testing on three different boards didn't show much > difference, even when specifically openssl's padlock engine was used > (actually it showed worse results on bigger blocks). Seems like padlock > instructions were not utilized in any case, at least if compared to some > results posted on the internet. Either I was doing something wrong or > openssl needs special patches. It was consistent with Linux results though. You can tell whether openssl is doing the cryptography in the kernel via /dev/crypto (and therefore potentially using the via_padlock.c module) as follows: % openssl speed aes-256-cbc Doing aes-256 cbc for 3s on 16 size blocks: 14899528 aes-256 cbc's in 2.98s Doing aes-256 cbc for 3s on 64 size blocks: 4030412 aes-256 cbc's in 2.97s [...] % openssl speed -evp aes-256-cbc Doing aes-256-cbc for 3s on 16 size blocks: 1732147 aes-256-cbc's in 0.76s Doing aes-256-cbc for 3s on 64 size blocks: 1373417 aes-256-cbc's in 0.43s [...] Note that the real time is about three seconds for each line, but the last number shows user time -- it's about three seconds _without_ `-evp', but under one second _with_ `-evp', which means that the computation is happening in the kernel. Of course, you will probably find that the throughput is not actually improved -- that's because the /dev/crypto userland interface is a piece of garbage that's useful only to check the results of crypto devices. Which is why I said that the module is useful only for in-kernel IPsec. > > > > On the side note, same goes to viadrmums module (it's i386 only now) > > > > but at least on VX900 I ended up with the crash, so I guess it may be > > > > incompatible with amd64 (though it builds successfully). Will try to > > > > test VX800 later on. > > > > I haven't tried viadrmums in a while. What was the crash? > > I am planning to submit PR once I will retest the driver with the latest > images. Actually, it may not be amd64 specific after all. Crash happens > during boot on match function, likely newer graphics are unsupported and > triggers some kassert? Can't say without the specific kassert (and ideally stack trace too). I don't see anything obvious in viadrm_match that would be problematic.
