From: "David S. Miller" <davem@davemloft.net>
To: David Dillow <dave@thedillows.org>
Cc: netdev@oss.sgi.com, dave@thedillows.org
Subject: Re: [RFC 2.6.10 2/22] xfrm: Add xfrm offload management calls to struct netdevice
Date: Fri, 21 Jan 2005 14:40:45 -0800 [thread overview]
Message-ID: <20050121144045.74d30ef2.davem@davemloft.net> (raw)
In-Reply-To: <20041230035000.11@ori.thedillows.org>
On Thu, 30 Dec 2004 03:48:34 -0500
David Dillow <dave@thedillows.org> wrote:
> # This is a BitKeeper generated diff -Nru style patch.
> #
> # ChangeSet
> # 2004/12/30 00:28:25-05:00 dave@thedillows.org
> # Add the xfrm offload management calls to struct netdevice.
> #
> # xfrm_state_add() is called for inbound xfrm states
> # xfrm_bundle_add() is called for outbound xfrm bundles
> # xfrm_state_del() is called for all offloaded xfrms,
> # inbound or outbound.
> #
> # If a driver adds NETIF_F_IPSEC to its features, it must
> # provide all three callbacks.
> #
> # Signed-off-by: David Dillow <dave@thedillows.org>
I have no problems with this interface. In fact, just about
whatever works for the card you have would be fine for an
initial implementation.
We know this interface will likely need to change over time
so we should explicitly mark these callbacks as in a state
of flux so that nobody who tries to play with this gets surprised
when we tweak it.
next prev parent reply other threads:[~2005-01-21 22:40 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-30 8:48 [RFC 2.6.10 0/22] Add hardware assist for IPSEC crypto David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 1/22] xfrm: Add direction information to xfrm_state David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 2/22] xfrm: Add xfrm offload management calls to struct netdevice David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 3/22] xfrm: Add offload management routines David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 4/22] xfrm: Try to offload inbound xfrm_states David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 5/22] xfrm: Attempt to offload bundled xfrm_states for outbound xfrms David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 6/22] xfrm: add a parameter to xfrm_prune_bundles() David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 7/22] xfrm: Allow device drivers to force recalculation of offloads David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 8/22] skbuff: Add routines to manage applied offloads per skb David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 9/22] AH: Split header initialization from zeroing of mutable fields David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 10/22] AH, ESP: Add offloading of outbound packets David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 11/22] AH, ESP: Add offloading of inbound packets David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 12/22] ethtool: Add support for crypto offload David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 13/22] typhoon: Make the ipsec descriptor match actual usage David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 14/22] typhoon: add inbound offload result processing David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 15/22] typhoon: add outbound offload processing David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 16/22] typhoon: collect crypto offload capabilities David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 17/22] typhoon: split out setting of offloaded tasks David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 18/22] typhoon: add validation of offloaded xfrm_states David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 19/22] typhoon: add loading of xfrm_states to hardware David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 20/22] typhoon: add management of outbound bundles David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 21/22] typhoon: add callbacks to support crypto offload David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 22/22] Add some documentation for the IPSEC " David Dillow
2005-01-21 23:23 ` [RFC 2.6.10 7/22] xfrm: Allow device drivers to force recalculation of offloads David S. Miller
2005-01-22 5:53 ` David Dillow
2005-01-26 6:11 ` David S. Miller
2005-01-21 23:21 ` [RFC 2.6.10 6/22] xfrm: add a parameter to xfrm_prune_bundles() David S. Miller
2004-12-30 23:34 ` [RFC 2.6.10 5/22] xfrm: Attempt to offload bundled xfrm_states for outbound xfrms Francois Romieu
2004-12-31 3:31 ` David Dillow
2005-01-21 23:20 ` David S. Miller
2005-01-22 5:53 ` David Dillow
2005-01-26 6:11 ` David S. Miller
2005-01-21 22:56 ` [RFC 2.6.10 4/22] xfrm: Try to offload inbound xfrm_states David S. Miller
2005-01-22 5:52 ` David Dillow
2005-01-26 6:13 ` David S. Miller
2005-01-21 22:47 ` [RFC 2.6.10 3/22] xfrm: Add offload management routines David S. Miller
2005-01-22 6:00 ` David Dillow
[not found] ` <1106373038.3691.39.camel@ori.thedillows.org>
[not found] ` <20050125221608.0cb067b2.davem@davemloft.net>
2005-01-26 21:30 ` David Dillow
2005-01-21 22:40 ` David S. Miller [this message]
2004-12-30 9:48 ` [RFC 2.6.10 1/22] xfrm: Add direction information to xfrm_state Jan-Benedict Glaw
2004-12-30 16:16 ` Dave Dillow
2004-12-30 16:36 ` Jan-Benedict Glaw
[not found] ` <200412301436.06653.ioe-lkml@axxeo.de>
2004-12-30 16:21 ` Dave Dillow
2005-01-21 22:38 ` David S. Miller
2005-01-22 5:50 ` David Dillow
2005-01-26 6:17 ` David S. Miller
2005-01-26 21:14 ` David Dillow
2005-01-21 22:35 ` [RFC 2.6.10 0/22] Add hardware assist for IPSEC crypto David S. Miller
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=20050121144045.74d30ef2.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=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).