[lkml]   [2007]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [CRYPTO] is it really optimized ?
     > > It seems trivial to keep the last key you were given and do a quick
    > > memcmp in your setkey method to see if it's different from the last
    > > key you pushed to hardware, and set a flag if it is. Then only do
    > > your set_key() if you have a new key to pass to hardware.
    > >
    > > I'm assuming the expense is in the aes_write() calls, and you could
    > > avoid them if you know you're not writing something new.

    > that's a wrong assumption. aes_write()/aes_read() are both used to
    > access to the controller and are slow (no cache involved).

    Sorry, I wasn't clear. I meant that the hardware access is what is
    slow, and that anything you do on the CPU is relatively cheap compared
    to that.

    So my suggestion is just to keep a cache (in CPU memory) of what you
    have already loaded into the HW, and before reloading the HW just
    check the cache and don't do the actual HW access if you're not going
    to change the HW contents. So you avoid any extra aes_write and
    aes_read calls in the cache hit case.

    This would have the advantage of making anything that does lots of
    bulk encryption fast without special casing ecryptfs.

    - R.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-17 19:37    [W:0.021 / U:32.784 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site