lkml.org 
[lkml]   [2003]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 13:46    [W:3.008 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site