Messages in this thread | | | Date | Thu, 3 Jul 2003 08:20:34 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] cryptoloop |
| |
Jari Ruusu <jari.ruusu@pp.inet.fi> wrote: > > Andries.Brouwer@cwi.nl wrote: > > akpm: > > > You'll note that loop.c goes from (page/offset/len) to (addr/len), > > > and this transfer function then immediately goes from (addr,len) > > > to (page/offset/len). That's rather silly .. > > > > Changing that would kill all existing modules that use the loop device. > > > > Maybe nobody cares. Then we can do so in a subsequent patch. > > I care. Please don't break the transfer function prototype.
Why?
> I don't know if you guys have realized it or not, but cryptoloop+cryptoapi > is the slowest possible loop crypto implementation on the planet. Before you > guys sacrifice loop performance with cryptoloop only stuff, you may want to > do google search for "loop-AES" (twice as fast on most modern boxes) and > choose to preserve fast interfaces that other implementations depend on.
It's not clear what point you're actually trying to make here. But it's worth pointing out that the current transfer function interface can be sped up (a bit) by going to a pageframe-based one. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |