[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081215182653.GC18346@linux-os.sc.intel.com>
Date: Mon, 15 Dec 2008 10:26:54 -0800
From: Suresh Siddha <suresh.b.siddha@...el.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: "Huang, Ying" <ying.huang@...el.com>,
"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
Sebastian Andrzej Siewior <linux-crypto@...breakpoint.cc>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"mingo@...e.hu" <mingo@...e.hu>,
"tglx@...utronix.de" <tglx@...utronix.de>
Subject: Re: [RFC PATCH crypto] AES: Add support to Intel AES-NI instructions
On Sun, Dec 14, 2008 at 07:38:42PM -0800, Herbert Xu wrote:
> On Mon, Dec 15, 2008 at 10:19:02AM +0800, Huang Ying wrote:
> >
> > The general x86 implementation is used as the fall back for new AES-NI
> > based implementation. Because AES-NI can not be used in kernel soft_irq
> > context. If crypto layer is used to access general x86 implementation,
>
> Why is that? The VIA PadLock also "touches" the SSE state but we still
> use it on softirq paths.
>
> In fact Suresh told me earlier that your AES instruction wasn't
> going to have the SSE problems that VIA had, is this not the case?
As Huang mentioned, AES instructions touch SSE registers and thus have
different requirements. I agree that we have to do some performance
analysis to come up with the optimized model.
thanks,
suresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists