[PATCH] crypto: make michael_block a function - Kernel

This is a discussion on [PATCH] crypto: make michael_block a function - Kernel ; Make the michael_block macro a function and change the calling function to take a struct michael_mic_ctx * and the value for the initial xor with ctx->l. Also open-code xswap in its one use in michael_block. Some use of get_unaligned is ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: [PATCH] crypto: make michael_block a function

  1. [PATCH] crypto: make michael_block a function

    Make the michael_block macro a function and change the calling
    function to take a struct michael_mic_ctx * and the value for
    the initial xor with ctx->l.

    Also open-code xswap in its one use in michael_block.

    Some use of get_unaligned is probably needed as an add-on.

    Signed-off-by: Harvey Harrison
    ---
    crypto/michael_mic.c | 55 +++++++++++++++++++++----------------------------
    1 files changed, 24 insertions(+), 31 deletions(-)

    diff --git a/crypto/michael_mic.c b/crypto/michael_mic.c
    index 9e917b8..792dbf9 100644
    --- a/crypto/michael_mic.c
    +++ b/crypto/michael_mic.c
    @@ -31,19 +31,18 @@ static inline u32 xswap(u32 val)
    return ((val & 0x00ff00ff) << 8) | ((val & 0xff00ff00) >> 8);
    }

    -
    -#define michael_block(l, r) \
    -do { \
    - r ^= rol32(l, 17); \
    - l += r; \
    - r ^= xswap(l); \
    - l += r; \
    - r ^= rol32(l, 3); \
    - l += r; \
    - r ^= ror32(l, 2); \
    - l += r; \
    -} while (0)
    -
    +static void michael_block(struct michael_mic_ctx *ctx, u32 val)
    +{
    + ctx->l ^= val;
    + ctx->r ^= rol32(ctx->l, 17);
    + ctx->l += ctx->r;
    + ctx->r ^= ((ctx->l & 0x00ff00ff) << 8) | ((ctx->l & 0xff00ff00) >> 8);
    + ctx->l += ctx->r;
    + ctx->r ^= rol32(ctx->l, 3);
    + ctx->l += ctx->r;
    + ctx->r ^= ror32(ctx->l, 2);
    + ctx->l += ctx->r;
    +}

    static void michael_init(struct crypto_tfm *tfm)
    {
    @@ -71,16 +70,14 @@ static void michael_update(struct crypto_tfm *tfm, const u8 *data,
    return;

    src = (const __le32 *)mctx->pending;
    - mctx->l ^= le32_to_cpup(src);
    - michael_block(mctx->l, mctx->r);
    + michael_block(mctx, le32_to_cpup(src));
    mctx->pending_len = 0;
    }

    src = (const __le32 *)data;

    while (len >= 4) {
    - mctx->l ^= le32_to_cpup(src++);
    - michael_block(mctx->l, mctx->r);
    + michael_block(mctx, le32_to_cpup(src++));
    len -= 4;
    }

    @@ -96,26 +93,22 @@ static void michael_final(struct crypto_tfm *tfm, u8 *out)
    struct michael_mic_ctx *mctx = crypto_tfm_ctx(tfm);
    u8 *data = mctx->pending;
    __le32 *dst = (__le32 *)out;
    + u32 tmp;

    /* Last block and padding (0x5a, 4..7 x 0) */
    + tmp = 0x5a;
    switch (mctx->pending_len) {
    - case 0:
    - mctx->l ^= 0x5a;
    - break;
    - case 1:
    - mctx->l ^= data[0] | 0x5a00;
    - break;
    - case 2:
    - mctx->l ^= data[0] | (data[1] << 8) | 0x5a0000;
    - break;
    case 3:
    - mctx->l ^= data[0] | (data[1] << 8) | (data[2] << 16) |
    - 0x5a000000;
    + tmp = (tmp << 8) | data[2];
    + case 2:
    + tmp = (tmp << 8) | data[1];
    + case 1:
    + tmp = (tmp << 8) | data[0];
    + case 0:
    break;
    }
    - michael_block(mctx->l, mctx->r);
    - /* l ^= 0; */
    - michael_block(mctx->l, mctx->r);
    + michael_block(mctx, tmp);
    + michael_block(mctx, 0);

    dst[0] = cpu_to_le32(mctx->l);
    dst[1] = cpu_to_le32(mctx->r);
    --
    1.5.5.1.570.g26b5e



    --
    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/

  2. Re: [PATCH] crypto: make michael_block a function

    * Harvey Harrison | 2008-05-15 23:17:17 [-0700]:

    >Make the michael_block macro a function and change the calling
    >function to take a struct michael_mic_ctx * and the value for
    >the initial xor with ctx->l.
    >
    >Also open-code xswap in its one use in michael_block.
    Does this change have any performance impact?
    The only user is wireless (I guess). Is it used frequently (sign every
    packet for instance) or once in a while (in every re-keying)?

    Sebastian
    --
    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/

  3. Re: [PATCH] crypto: make michael_block a function

    On Fri, 2008-05-16 at 09:01 +0200, Sebastian Siewior wrote:
    > * Harvey Harrison | 2008-05-15 23:17:17 [-0700]:
    >
    > >Make the michael_block macro a function and change the calling
    > >function to take a struct michael_mic_ctx * and the value for
    > >the initial xor with ctx->l.
    > >
    > >Also open-code xswap in its one use in michael_block.
    > Does this change have any performance impact?
    > The only user is wireless (I guess). Is it used frequently (sign every
    > packet for instance) or once in a while (in every re-keying)?

    Every packet. I have no idea whether it has performance impact, very
    hard to even guess.

    johannes

    -----BEGIN PGP SIGNATURE-----
    Comment: Johannes Berg (powerbook)

    iQIVAwUASC1BXKVg1VMiehFYAQKz0Q/9E2uiWOpCpogcsNURaB+9TDLiY8+zonoP
    Lu4IBlablgimvDVvO7SMNpH+jBYkBS/5vMC+hkHJhCexsI3tMjEY0mDpjJrACp+m
    xzIqXVr7R0anBzJIDa7yUqa+u+u8gbvtKaDr3c5e81pTxn13pF woYy305ncRUH24
    7rAca7dCuycXFnwhIFUzLVgwvBREb3bl1LXuSYfjMj95OxxXYj tgUESdTBfByXkm
    1734zE/9ff6H2fii7HLg9imOEy+FfFXGPBE61tx8g2Cw5361Qf8+tTkNL XJ5GpkA
    t5Qf/xw/d4npuxvhhsiXx0JXA3apWNFMm2yFIowBxRQxtk7KKtvnRakJma ishfHY
    I3AQUgm+bsJPkCuKRhddBlmZIWC+3oz1M3J3AW9100WnWE+hKe X1gn6IHFLeYCKD
    cruLaFBQ+2VmRNGFzmP9XanlLjS34Iev75U3IAn71qDblR9q2h Pcpx9DN28gpEcE
    lzN7nh2P9VSTxW1ol7HRIyYoYXPCGwLFxIZdR38m5mPdwP0r6J 0wCGbU0U8bHZZL
    0uuwf7ZrorZBVyP0HEYA6WaafLaVWVghQy12Zs4Z6OyhwrfdGP n1oCRoJhHiSPEo
    OX1Nbv/0USMGzasAHm8jrY1zkdbbZvOrJcWC1O6siMRvzHksqFo5601ol fKl9ymT
    PgY0XvvkxTg=
    =fseh
    -----END PGP SIGNATURE-----

  4. Re: [PATCH] crypto: make michael_block a function

    On Fri, 2008-05-16 at 10:10 +0200, Johannes Berg wrote:
    > On Fri, 2008-05-16 at 09:01 +0200, Sebastian Siewior wrote:
    > > * Harvey Harrison | 2008-05-15 23:17:17 [-0700]:
    > >
    > > >Make the michael_block macro a function and change the calling
    > > >function to take a struct michael_mic_ctx * and the value for
    > > >the initial xor with ctx->l.
    > > >
    > > >Also open-code xswap in its one use in michael_block.
    > > Does this change have any performance impact?
    > > The only user is wireless (I guess). Is it used frequently (sign every
    > > packet for instance) or once in a while (in every re-keying)?
    >
    > Every packet. I have no idea whether it has performance impact, very
    > hard to even guess.
    >

    Well, the code-size difference is significant (about 200 bytes smaller
    on X86-32). This macro is essentially an inline function that is pretty
    large.

    Attached find the objdump -d of the original and after the patch. As it
    is, this code isn't used anywhere that I can find as mac80211 has its
    own implementation, I'm trying to see if there is much advantage in
    keeping the private version over moving to the crypto one.

    Harvey

  5. Re: [PATCH] crypto: make michael_block a function

    * Harvey Harrison | 2008-05-16 08:52:03 [-0700]:

    >Well, the code-size difference is significant (about 200 bytes smaller
    >on X86-32). This macro is essentially an inline function that is pretty
    >large.

    Can you please apply the attached patch and run
    | modprobe tcrypt mode=314

    before and after your patch?

    I get the following numbers on one of my maschines:

    before:
    ~~~~~~~
    |test 0 ( 16 byte blocks, 16 bytes per update, 1 updates): 122 cycles/operation, 7 cycles/byte
    |test 1 ( 64 byte blocks, 16 bytes per update, 4 updates): 370 cycles/operation, 5 cycles/byte
    |test 2 ( 64 byte blocks, 64 bytes per update, 1 updates): 216 cycles/operation, 3 cycles/byte
    |test 3 ( 256 byte blocks, 16 bytes per update, 16 updates): 1304 cycles/operation, 5 cycles/byte
    |test 4 ( 256 byte blocks, 64 bytes per update, 4 updates): 746 cycles/operation, 2 cycles/byte
    |test 5 ( 256 byte blocks, 256 bytes per update, 1 updates): 592 cycles/operation, 2 cycles/byte
    |test 6 ( 1024 byte blocks, 16 bytes per update, 64 updates): 5040 cycles/operation, 4 cycles/byte
    |test 7 ( 1024 byte blocks, 256 bytes per update, 4 updates): 2252 cycles/operation, 2 cycles/byte
    |test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates): 2098 cycles/operation, 2 cycles/byte
    |test 9 ( 2048 byte blocks, 16 bytes per update, 128 updates): 10021 cycles/operation, 4 cycles/byte
    |test 10 ( 2048 byte blocks, 256 bytes per update, 8 updates): 4446 cycles/operation, 2 cycles/byte
    |test 11 ( 2048 byte blocks, 1024 bytes per update, 2 updates): 4167 cycles/operation, 2 cycles/byte
    |test 12 ( 2048 byte blocks, 2048 bytes per update, 1 updates): 4106 cycles/operation, 2 cycles/byte
    |test 13 ( 4096 byte blocks, 16 bytes per update, 256 updates): 19982 cycles/operation, 4 cycles/byte
    |test 14 ( 4096 byte blocks, 256 bytes per update, 16 updates): 8833 cycles/operation, 2 cycles/byte
    |test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates): 8275 cycles/operation, 2 cycles/byte
    |test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates): 8122 cycles/operation, 1 cycles/byte
    |test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates): 39906 cycles/operation, 4 cycles/byte
    |test 18 ( 8192 byte blocks, 256 bytes per update, 32 updates): 17607 cycles/operation, 2 cycles/byte
    |test 19 ( 8192 byte blocks, 1024 bytes per update, 8 updates): 16492 cycles/operation, 2 cycles/byte
    |test 20 ( 8192 byte blocks, 4096 bytes per update, 2 updates): 16214 cycles/operation, 1 cycles/byte
    |test 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 16173 cycles/operation, 1 cycles/byte

    after:
    ~~~~~~
    |test 0 ( 16 byte blocks, 16 bytes per update, 1 updates): 175 cycles/operation, 10 cycles/byte
    |test 1 ( 64 byte blocks, 16 bytes per update, 4 updates): 510 cycles/operation, 7 cycles/byte
    |test 2 ( 64 byte blocks, 64 bytes per update, 1 updates): 342 cycles/operation, 5 cycles/byte
    |test 3 ( 256 byte blocks, 16 bytes per update, 16 updates): 1813 cycles/operation, 7 cycles/byte
    |test 4 ( 256 byte blocks, 64 bytes per update, 4 updates): 1182 cycles/operation, 4 cycles/byte
    |test 5 ( 256 byte blocks, 256 bytes per update, 1 updates): 1013 cycles/operation, 3 cycles/byte
    |test 6 ( 1024 byte blocks, 16 bytes per update, 64 updates): 7026 cycles/operation, 6 cycles/byte
    |test 7 ( 1024 byte blocks, 256 bytes per update, 4 updates): 3869 cycles/operation, 3 cycles/byte
    |test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates): 3701 cycles/operation, 3 cycles/byte
    |test 9 ( 2048 byte blocks, 16 bytes per update, 128 updates): 13975 cycles/operation, 6 cycles/byte
    |test 10 ( 2048 byte blocks, 256 bytes per update, 8 updates): 7662 cycles/operation, 3 cycles/byte
    |test 11 ( 2048 byte blocks, 1024 bytes per update, 2 updates): 7346 cycles/operation, 3 cycles/byte
    |test 12 ( 2048 byte blocks, 2048 bytes per update, 1 updates): 7282 cycles/operation, 3 cycles/byte
    |test 13 ( 4096 byte blocks, 16 bytes per update, 256 updates): 27875 cycles/operation, 6 cycles/byte
    |test 14 ( 4096 byte blocks, 256 bytes per update, 16 updates): 15247 cycles/operation, 3 cycles/byte
    |test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates): 14615 cycles/operation, 3 cycles/byte
    |test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates): 14447 cycles/operation, 3 cycles/byte
    |test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates): 55673 cycles/operation, 6 cycles/byte
    |test 18 ( 8192 byte blocks, 256 bytes per update, 32 updates): 30416 cycles/operation, 3 cycles/byte
    |test 19 ( 8192 byte blocks, 1024 bytes per update, 8 updates): 29155 cycles/operation, 3 cycles/byte
    |test 20 ( 8192 byte blocks, 4096 bytes per update, 2 updates): 28839 cycles/operation, 3 cycles/byte
    |test 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 28794 cycles/operation, 3 cycles/byte


    >
    >Harvey

    Sebastian

    ---
    crypto/tcrypt.c | 4 ++++
    1 files changed, 4 insertions(+), 0 deletions(-)

    diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
    index 1ab8c01..c0040d5 100644
    --- a/crypto/tcrypt.c
    +++ b/crypto/tcrypt.c
    @@ -1761,6 +1761,10 @@ static void do_test(void)
    test_hash_speed("sha224", sec, generic_hash_speed_template);
    if (mode > 300 && mode < 400) break;

    + case 314:
    + test_hash_speed("michael_mic", sec, generic_hash_speed_template);
    + if (mode > 300 && mode < 400) break;
    +
    case 399:
    break;

    --
    1.5.4.3

    --
    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/
+ Reply to Thread
« [PATCH] power_supply: support CHARGE_NOW in OLPC battery | [regression bisected] HR-timers bug >=2.6.25 »