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 linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html