From: Christoph Hellwig <hch@infradead.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Christoph Hellwig <hch@infradead.org>,
"David S. Miller" <davem@davemloft.net>,
James Morris <jmorris@redhat.com>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
netdev@oss.sgi.com
Subject: Re: [RFC] Replace scatterlist with crypto_frag
Date: Mon, 6 Jun 2005 13:09:14 +0100 [thread overview]
Message-ID: <20050606120914.GA8317@infradead.org> (raw)
In-Reply-To: <20050606115939.GA399@gondor.apana.org.au>
On Mon, Jun 06, 2005 at 09:59:39PM +1000, Herbert Xu wrote:
> On Sat, Jun 04, 2005 at 12:58:53PM +0100, Christoph Hellwig wrote:
> >
> > the usage of 16bit counters in bio_vec doesn't make sense, and if did
> > all others would have to move to 32bit aswell (in case we started
> > supporting page sizes that aren't addressable by 16bits)
>
> You know what? The more I think about this the more I think that your
> idea is brilliant. The reason is that the two main users of crypto API
> happen to be in possession of bio_vec and skb_frag_t respectively.
>
> Had we merged the three structures, they would not have to copy the
> structures as they do now or even worse, process the buffers one-by-one
> as dmcrypt is doing.
>
> Back to the topic of 16-bit vs. 32-bit counters. Could we do something
> like this?
>
> #if (PAGE_SHIFT > 16) || (BITS_PER_LONG > 32)
what is the BITS_PER_LONG check for?
> typedef unsigned int page_offset_t
> #else
> typedef unsigned short page_offset_t
> #endif
the name is a) a little long and b) easy to confuse with pgoff_t as used in
the pagecache. I'm not sure what a better name would be.
We probably shouldn't care about this as the networking code didn't handle
larger offsets either.
next prev parent reply other threads:[~2005-06-06 12:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-03 23:46 [RFC] Replace scatterlist with crypto_frag Herbert Xu
2005-06-04 0:02 ` Jeff Garzik
2005-06-04 0:42 ` Herbert Xu
2005-06-04 4:39 ` James Morris
2005-06-04 4:51 ` Herbert Xu
2005-06-04 5:23 ` James Morris
2005-06-04 5:33 ` Herbert Xu
2005-06-04 10:00 ` Evgeniy Polyakov
2005-06-04 9:55 ` Evgeniy Polyakov
2005-06-04 9:58 ` Herbert Xu
2005-06-04 10:17 ` Evgeniy Polyakov
2005-06-04 10:22 ` Herbert Xu
2005-06-04 10:29 ` Evgeniy Polyakov
2005-06-04 10:32 ` Herbert Xu
2005-06-04 10:40 ` Evgeniy Polyakov
2005-06-06 22:36 ` David S. Miller
2005-06-04 11:23 ` Christoph Hellwig
2005-06-04 11:26 ` Herbert Xu
2005-06-04 11:58 ` Christoph Hellwig
2005-06-06 11:59 ` Herbert Xu
2005-06-06 12:09 ` Christoph Hellwig [this message]
2005-06-06 12:40 ` Herbert Xu
2005-06-06 13:30 ` Christoph Hellwig
2005-06-06 22:46 ` David S. Miller
2005-06-06 23:04 ` Herbert Xu
2005-06-06 23:09 ` David S. Miller
2005-06-06 23:14 ` Herbert Xu
2005-06-06 23:18 ` David S. Miller
2005-06-06 23:20 ` Herbert Xu
2005-06-06 23:05 ` Jeff Garzik
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=20050606120914.GA8317@infradead.org \
--to=hch@infradead.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=jmorris@redhat.com \
--cc=linux-crypto@vger.kernel.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).