linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: n.balaji@gdatech.co.in
To: "David McCullough" <david_mccullough@au.securecomputing.com>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	n.balaji@gdatech.co.in
Subject: Asynchronous Crypto suppor for MPC8360E's Security Engine
Date: Tue, 19 Dec 2006 16:54:02 +0530 (IST)	[thread overview]
Message-ID: <48805.202.144.30.226.1166527442.squirrel@mail.gdatech.co.in> (raw)
In-Reply-To: 

Hi,
  I am working on MPC8360E Security Engine. I have ported the Openswan
2.4.5(IPSec --KLIPS) with OCF to MPC8360E's Security Engine (Talitos).
Encryption and Decryption is working. But when I check the performance of
Talitos with netio benchmark Tool, IPSec S/W Algorithms is giving more
bandwidth than Talitos.
  I do not know that why Talitos is giving less bandwidth and any probelm
in Openswan or OCF or Talitos driver or Talitos H/W. Please give your
suggestions and if you have any link related to Talitos, send to me.

  Linux kernel version is 2.6.11.

  We tested the IPSec performance by netio tool. The output is

Without IPSec :
-------------
Packet size  1k bytes:  8735 KByte/s Tx,  11242 KByte/s Rx.
Packet size  2k bytes:  8723 KByte/s Tx,  11001 KByte/s Rx.
Packet size  4k bytes:  8730 KByte/s Tx,  10159 KByte/s Rx.
Packet size  8k bytes:  8762 KByte/s Tx,  10986 KByte/s Rx.
Packet size 16k bytes:  8725 KByte/s Tx,  10997 KByte/s Rx.
Packet size 32k bytes:  8725 KByte/s Tx,  11002 KByte/s Rx.

IPSec in S/W :
------------
Packet size  1k bytes:  884 KByte/s Tx,  1120 KByte/s Rx.
Packet size  2k bytes:  1234 KByte/s Tx,  1149 KByte/s Rx.
Packet size  4k bytes:  1209 KByte/s Tx,  1178 KByte/s Rx.
Packet size  8k bytes:  885 KByte/s Tx,  1155 KByte/s Rx.
Packet size 16k bytes:  1184 KByte/s Tx,  1197 KByte/s Rx.
Packet size 32k bytes:  1194 KByte/s Tx,  1206 KByte/s Rx.

IPSec in H/W :
-------------
Packet size  1k bytes:  55978 Byte/s Tx,  484 KByte/s Rx.
Packet size  2k bytes:  57685 Byte/s Tx,  577 KByte/s Rx.
Packet size  4k bytes:  57344 Byte/s Tx,  812 KByte/s Rx.
Packet size  8k bytes:  58709 Byte/s Tx,  438 KByte/s Rx.
Packet size 16k bytes:  60074 Byte/s Tx,  627 KByte/s Rx.
Packet size 32k bytes:  60072 Byte/s Tx,  575 KByte/s Rx.

 We sholud get more bandwidth when we test through IPSec H/W. But We are
getting less bandwidth compare to IPSec S/W.

 But When we transmit 32 MB size file through tftp, it is transmitted in
139.0 seconds in IPSec S/W. When we transmit the same file, it is
transmitted in 136.2 seconds.

 When we ping the system, we got the reply in 2ms in IPSec S/W and 1ms in
IPSec H/W.

-Thanks
 N.Balaji

             reply	other threads:[~2006-12-19 11:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-19 11:24 n.balaji [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-12-15  7:32 Asynchronous Crypto suppor for MPC8360E's Security Engine n.balaji

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48805.202.144.30.226.1166527442.squirrel@mail.gdatech.co.in \
    --to=n.balaji@gdatech.co.in \
    --cc=david_mccullough@au.securecomputing.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).