[RFC PATCH v3 0/4] Simplify kernel-mode NEON

[Dave.Martin@arm.com (Dave Martin)]

On Wed, May 31, 2017 at 11:07:56AM +0000, Ard Biesheuvel wrote:
> On 31 May 2017 at 10:08, Dave Martin <Dave.Martin@arm.com> wrote:
> > On Wed, May 31, 2017 at 08:41:01AM +0000, Ard Biesheuvel wrote:

[...]

> > Something like [1] below?  Either way, it probably makes sense for that
> > stub function to be added by your series.
> >
> 
> Pretty much, yeah. But don't forget to remove simd.h from
> arch/arm64/include/asm/Kbuild

Oh wow, I thought that was done by magic.

> >> BTW I got my ZD1211 working on my MacchiatioBin board. The performance
> >> is terrible, but that should not matter: if I can saturate a CPU doing
> >
> > Do you mean that my series causes a performance regression here, or is
> > the performance terrible anyway?
> >
> 
> No, the performance is terrible, which shouldn't matter per se, but it
> would be nice if the load induced by the mac80211 were visible in
> 'top' as wait, sys or whatever-it-is-called time. Currently, the 3
> Mbit/s throughput combined with the 2.2 cycles per byte performance of
> the AES-CCM code makes the code unnoticeable.
> 
> >> NEON from userland and/or kernel process context, the softirq
> >> interruptions by the mac80211 code should exercise the updated code
> >> paths. I haven't tried that yet: let me get the code changes out
> >> today, so you can put your stuff on top. Then we can give it a good
> >> spin.
> >
> > That would be great, thanks.
> >
> 
> I have updated my branch here:
> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=kernel-mode-neon

Looks good.

> I removed all kernel_neon_begin_partial() invocations as well.

OK, I will drop that from my series.

Cheers
---Dave