On (12/02/15 11:56), David Laight wrote:
> > Gbps peak cpu util
> > esp-null 1.8 71%
> > aes-gcm-c-256 1.6 79%
> > aes-ccm-a-128 0.7 96%
> >
> > That trend made me think that if we can get esp-null to be as close
> > as possible to GSO/GRO, the rest will follow closely behind.
>
> That's not how I read those figures.
> They imply to me that there is a massive cost for the actual encryption
> (particularly for aes-ccm-a-128) - so whatever you do to the esp-null
> case won't help.
I'm not a crypto expert, but my understanding is that the CCM mode
is the "older" encryption algorithm, and GCM is the way of the future.
Plus, I think the GCM mode has some type of h/w support (hence the
lower cpu util)
I'm sure that crypto has a cost, not disputing that, but my point
was that 1.8 -> 1.6 -> 0.7 is a curve with a much gentler slope than
the 9 Gbps (clear traffic, GSO, GRO)
-> 4 Gbps (clear, no gro, gso)
-> 1.8 (esp-null)
That steeper slope smells of s/w perf that we need to resolve first,
before getting into the work of faster crypto?
> One way to get a view of the cost of the encryption (and copies)
> is to do the operation twice.
I could also just instrument it with perf tracepoints, if that
data is interesting
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
