netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Dillow <dave@thedillows.org>
To: netdev@oss.sgi.com
Cc: dave@thedillows.org
Subject: [RFC BK 16/22] xfrm offload v2: typhoon: collect crypto offload capabilities
Date: Mon, 10 Jan 2005 10:37:02 -0500	[thread overview]
Message-ID: <20040110014300.25@ori.thedillows.org> (raw)
In-Reply-To: 20040110014300.24@ori.thedillows.org

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/01/10 00:57:15-05:00 dave@thedillows.org 
#   Collect some information about the Typhoon's offload capabilities,
#   and store it for future use.
#   
#   Signed-off-by: David Dillow <dave@thedillows.org>
# 
# drivers/net/typhoon.h
#   2005/01/10 00:56:57-05:00 dave@thedillows.org +14 -0
#   Add the reply message format for the crypto capability query command.
#   
#   Signed-off-by: David Dillow <dave@thedillows.org>
# 
# drivers/net/typhoon.c
#   2005/01/10 00:56:57-05:00 dave@thedillows.org +56 -0
#   Collect some information about the Typhoon's offload capabilities,
#   and store it for future use.
#   
#   Signed-off-by: David Dillow <dave@thedillows.org>
# 
diff -Nru a/drivers/net/typhoon.c b/drivers/net/typhoon.c
--- a/drivers/net/typhoon.c	2005-01-10 01:17:33 -05:00
+++ b/drivers/net/typhoon.c	2005-01-10 01:17:33 -05:00
@@ -304,6 +304,12 @@
 	u16			wol_events;
 	u32			offload;
 
+	u16			tx_sa_max;
+	u16			rx_sa_max;
+	u16			tx_sa_avail;
+	u16			rx_sa_avail;
+	int			sa_count;
+
 	/* unused stuff (future use) */
 	int			capabilities;
 	struct transmit_ring 	txHiRing;
@@ -2104,6 +2110,53 @@
 	return 0;
 }
 
+static inline int
+typhoon_ipsec_init(struct typhoon *tp)
+{
+	struct cmd_desc xp_cmd;
+	struct resp_desc xp_resp;
+	struct ipsec_info_desc *info = (struct ipsec_info_desc *) &xp_resp;
+	u16 last_tx, last_rx, last_cap;
+	int err;
+
+	last_tx = tp->tx_sa_max;
+	last_rx = tp->rx_sa_max;
+	last_cap = tp->capabilities;
+
+	INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_IPSEC_INFO);
+	err = typhoon_issue_command(tp, 1, &xp_cmd, 1, &xp_resp);
+	if(err < 0)
+		goto out;
+
+	/* We're not up yet, so no need to lock this -- we cannot modify
+	 * these fields yet.
+	 */
+	tp->tx_sa_avail = tp->tx_sa_max = le16_to_cpu(info->tx_sa_max);
+	tp->rx_sa_avail = tp->rx_sa_max = le16_to_cpu(info->rx_sa_max);
+	tp->sa_count = 0;
+
+	/* Typhoon2 was originally going to have variable crypto capabilities,
+	 * subject to registration with 3Com. It appears they have decided
+	 * to just enable 3DES as well.
+	 */
+	if(tp->capabilities & TYPHOON_CRYPTO_VARIABLE) {
+		tp->capabilities &= ~TYPHOON_CRYPTO_VARIABLE;
+		tp->capabilities |= TYPHOON_CRYPTO_DES | TYPHOON_CRYPTO_3DES;
+	}
+
+	if(last_tx != tp->tx_sa_max || last_rx != tp->rx_sa_max ||
+					last_cap != tp->capabilities) {
+		printk(KERN_INFO "%s: IPSEC offload %s%s %d Tx %d Rx\n",
+			tp->name,
+			tp->capabilities & TYPHOON_CRYPTO_DES ? "DES " : "",
+			tp->capabilities & TYPHOON_CRYPTO_3DES ? "3DES" : "",
+			tp->tx_sa_max, tp->rx_sa_max);
+	}
+
+out:
+	return err;
+}
+
 static int
 typhoon_start_runtime(struct typhoon *tp)
 {
@@ -2126,6 +2179,9 @@
 		err = -EIO;
 		goto error_out;
 	}
+
+	if(typhoon_ipsec_init(tp))
+		goto error_out;
 
 	INIT_COMMAND_NO_RESPONSE(&xp_cmd, TYPHOON_CMD_SET_MAX_PKT_SIZE);
 	xp_cmd.parm1 = cpu_to_le16(PKT_BUF_SZ);
diff -Nru a/drivers/net/typhoon.h b/drivers/net/typhoon.h
--- a/drivers/net/typhoon.h	2005-01-10 01:17:33 -05:00
+++ b/drivers/net/typhoon.h	2005-01-10 01:17:33 -05:00
@@ -487,6 +487,20 @@
 	u32 unused2;
 } __attribute__ ((packed));
 
+/* TYPHOON_CMD_READ_IPSEC_INFO response descriptor
+ */
+struct ipsec_info_desc {
+	u8  flags;
+	u8  numDesc;
+	u16 cmd;
+	u16 seqNo;
+	u16 des_enabled;
+	u16 tx_sa_max;
+	u16 rx_sa_max;
+	u16 tx_sa_count;
+	u16 rx_sa_count;
+} __attribute__ ((packed));
+
 /* TYPHOON_CMD_SET_OFFLOAD_TASKS bits (cmd.parm2 (Tx) & cmd.parm3 (Rx))
  * This is all for IPv4.
  */

  reply	other threads:[~2005-01-10 15:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-10 15:36 [RFC BK 0/22] xfrm offload v2: Add hardware assist for IPSEC crypto David Dillow
2005-01-10 15:36 ` [RFC BK 1/22] xfrm offload v2: Add direction information to xfrm_state David Dillow
2005-01-10 15:36   ` [RFC BK 2/22] xfrm offload v2: Add xfrm offload management calls to struct netdevice David Dillow
2005-01-10 15:36     ` [RFC BK 3/22] xfrm offload v2: Add offload management routines David Dillow
2005-01-10 15:36       ` [RFC BK 4/22] xfrm offload v2: Try to offload inbound xfrm_states David Dillow
2005-01-10 15:37         ` [RFC BK 5/22] xfrm offload v2: Attempt to offload bundled xfrm_states for outbound xfrms David Dillow
2005-01-10 15:37           ` [RFC BK 6/22] xfrm offload v2: add a parameter to xfrm_prune_bundles() David Dillow
2005-01-10 15:37             ` [RFC BK 7/22] xfrm offload v2: Allow device drivers to force recalculation of offloads David Dillow
2005-01-10 15:37               ` [RFC BK 8/22] xfrm offload v2: Add routines to manage applied offloads per skb David Dillow
2005-01-10 15:37                 ` [RFC BK 9/22] xfrm offload v2: Split AH header initialization from zeroing of mutable fields David Dillow
2005-01-10 15:37                   ` [RFC BK 10/22] xfrm offload v2: Add offloading of outbound AH & ESP packets David Dillow
2005-01-10 15:37                     ` [RFC BK 11/22] xfrm offload v2: Add offloading of inbound " David Dillow
2005-01-10 15:37                       ` [RFC BK 12/22] xfrm offload v2: Add ethtool support for crypto offload control David Dillow
2005-01-10 15:37                         ` [RFC BK 13/22] xfrm offload v2: typhoon: Make the ipsec descriptor match actual usage David Dillow
2005-01-10 15:37                           ` [RFC BK 14/22] xfrm offload v2: typhoon: add inbound offload result processing David Dillow
2005-01-10 15:37                             ` [RFC BK 15/22] xfrm offload v2: typhoon: add outbound offload processing David Dillow
2005-01-10 15:37                               ` David Dillow [this message]
2005-01-10 15:37                                 ` [RFC BK 17/22] xfrm offload v2: typhoon: split out setting of offloaded tasks David Dillow
2005-01-10 15:37                                   ` [RFC BK 18/22] xfrm offload v2: typhoon: add validation of offloaded xfrm_states David Dillow
2005-01-10 15:37                                     ` [RFC BK 19/22] xfrm offload v2: typhoon: add loading of xfrm_states to hardware David Dillow
2005-01-10 15:37                                       ` [RFC BK 20/22] xfrm offload v2: typhoon: add management of outbound bundles David Dillow
2005-01-10 15:37                                         ` [RFC BK 21/22] xfrm offload v2: typhoon: add callbacks to support crypto offload David Dillow
2005-01-10 15:37                                           ` [RFC BK 22/22] xfrm offload v2: Add some documentation for the IPSEC " David Dillow
2005-01-17 19:00 ` [RFC BK 0/22] xfrm offload v2: Add hardware assist for IPSEC crypto James Morris
2005-01-20 17:22   ` Dave Dillow

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=20040110014300.25@ori.thedillows.org \
    --to=dave@thedillows.org \
    --cc=netdev@oss.sgi.com \
    /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).