Re: [PATCH v3 0/3] crypto: crct10dif assembly cleanup and optimizations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 30 Jan 2019 at 10:13, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Wed, Jan 30, 2019 at 09:33:57AM +0100, Ard Biesheuvel wrote:
> >
> > So what remains is the way these implementations are encapsulated by
> > the crct10dif() library function, which is raster nasty, making
> > CRC-T10DIF an excellent use case to discuss whether we can make any
> > improvements to address some of the concerns that were also raised in
> > the zinc discussion. I threw some code together a while ago [0] (and
> > posted it as well, IIRC). In the mean time, a 'static call'
> > infrastructure is being proposed that could be used in a similar way
> > to avoid function pointers. I'm also interested in hearing opinions on
> > whether the indirect call overhead is actually significant in use
> > cases such as this one.
>
> I think even if the overhead wasn't significant it would still make
> sense to make the move just for the sake of simplicity.
>

Agreed, we should simplify this if we can.

However, my question is whether in this particular case, a simple
indirect call via a function pointer is /so/ much worse than a direct
call that relies on code patching techniques that are different on
every arch (and may rely on objtool or GCC plugins) that the extra
complexity is justified.



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux