On Tue, Jun 1, 2021 at 11:21 PM Christopher M. Riedl
wrote:
> On Thu May 20, 2021 at 3:59 PM EDT, Maamoun TK wrote:
> > On Thu, May 20, 2021 at 10:06 PM Niels Möller
> > wrote:
> >
> > > "Christopher M. Riedl" writes:
> > >
> > > > So in total, if we assume an ideal (but impossible) zero-cost
On Thu May 20, 2021 at 3:59 PM EDT, Maamoun TK wrote:
> On Thu, May 20, 2021 at 10:06 PM Niels Möller
> wrote:
>
> > "Christopher M. Riedl" writes:
> >
> > > So in total, if we assume an ideal (but impossible) zero-cost version
> > > for memxor, memxor3, and gcm_fill and avoid permutes via ISA
On Thu, May 20, 2021 at 10:06 PM Niels Möller wrote:
> "Christopher M. Riedl" writes:
>
> > So in total, if we assume an ideal (but impossible) zero-cost version
> > for memxor, memxor3, and gcm_fill and avoid permutes via ISA 3.0 vector
> > load/stores we can only account for 11.82
"Christopher M. Riedl" writes:
> So in total, if we assume an ideal (but impossible) zero-cost version
> for memxor, memxor3, and gcm_fill and avoid permutes via ISA 3.0 vector
> load/stores we can only account for 11.82 cycles/block; leaving 4.97
> cycles/block as an additional benefit of the
On Mon Apr 5, 2021 at 2:39 AM CDT, Niels Möller wrote:
> "Christopher M. Riedl" writes:
>
> > An implementation combining AES+GCM _can potentially_ yield significant
> > performance boosts by allowing for increased instruction parallelism,
> > avoiding
> > C-function call overhead, more
"Christopher M. Riedl" writes:
> An implementation combining AES+GCM _can potentially_ yield significant
> performance boosts by allowing for increased instruction parallelism, avoiding
> C-function call overhead, more flexibility in assembly fine-tuning, etc. This
> series provides such an
Hi!
This series introduces a mechanism to support arch specific, combined AES+GCM
{en,de}cryption functions. These functions are stubbed by default and will
fall-back to the separate hash and crypt functions if no arch override exists.
The arch override can be provided either at build time via
