On Mon, 2005-02-14 at 10:16 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > First, one has to make kmap fallible.
>
> I think it would be relatively simple and sane to modify the existing
> kmap() implementations to add a new try_kmap() which is atomic and return
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> First, one has to make kmap fallible.
I think it would be relatively simple and sane to modify the existing
kmap() implementations to add a new try_kmap() which is atomic and returns
failure if it would have needed to sleep.
That being said, kmap()
On Mon, 2005-02-14 at 09:07 -0800, David S. Miller wrote:
> On Mon, 14 Feb 2005 18:06:39 +0100
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> > There is nothing wrong with having special methods, that lack generality
> > but are superior in performance. There is something wrong, when there
> >
On Mon, 14 Feb 2005 18:06:39 +0100
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> There is nothing wrong with having special methods, that lack generality
> but are superior in performance. There is something wrong, when there
> are no other. And there are no other for holding three kmappings or m
On Mon, 2005-02-14 at 07:56 -0800, David S. Miller wrote:
> On Mon, 14 Feb 2005 14:20:34 +0100
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> > Conclusion: The idea of high-mem and low-mem seperation is fundamentally
> > broken. The limitation of page table entries to a fixed set is causing
>
On Mon, 14 Feb 2005 14:20:34 +0100
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> Conclusion: The idea of high-mem and low-mem seperation is fundamentally
> broken. The limitation of page table entries to a fixed set is causing
> more complications than it solves. Laziness to do things right at me
On Thu, 2005-02-10 at 12:54 -0500, James Morris wrote:
> Making a generic N-way scatterlist processor is pointless
> overengineering, causing new problems with non-trivial solutions, for
> no benefit whatsoever.
I respectfully disagree. I spend the last few days thinking about a
solution about op
On Thu, Feb 10, 2005 at 12:17:24PM +0100, Fruhwirth Clemens wrote:
> On Thu, 2005-02-10 at 02:33 -0800, Andrew Morton wrote:
> > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
> > > > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
On Thu, 10 Feb 2005 02:33:44 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Is there an easy way to bring pages to lowmem? The cryptoapi is called
> > from the backlog of the networking stack, which is assigned in irq
> > context first and processed softirq context.
>
> Are networking frames
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
> Why should I pass the first thing of size X as scatterlist, and the
> second thing of size X as linear buffer?
>
> I could do that. It would be reasonable, because tweaks are more likely
> to be generated than transmitted, read or whatever. But wha
On Thu, 2005-02-10 at 12:02 -0500, James Morris wrote:
> On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
>
> > Hm, alright. So I'm going take the internal of kmap_atomic into
> > scatterwalk.c. to test if the page is in highmem, with PageHighMem. If
> > it is, I'm going to kmap_atomic and mark the f
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
> Hm, alright. So I'm going take the internal of kmap_atomic into
> scatterwalk.c. to test if the page is in highmem, with PageHighMem. If
> it is, I'm going to kmap_atomic and mark the fixmap as used. If it's
> not, I do the "mapping" on my own with p
On Thu, 2005-02-10 at 02:33 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
> > > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> > > Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
>
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
> > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> > >
> > > It must be
> > > possible to process more than 2 mappings in softirq context.
> >
> > Adding a few more fixmap slots wouldn't hurt
On Wed, 2005-02-09 at 20:42 -0500, James Morris wrote:
> On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
>
> > Because a tweak is different from an IV. There can be an arbitrary
> > number of tweaks. For instance, EME takes 1 tweak per 512 bytes. If you
> > have a 4k page to encrypt, you have to pro
On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > It must be
> > possible to process more than 2 mappings in softirq context.
>
> Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
> arbitrarily large number of the
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
> Because a tweak is different from an IV. There can be an arbitrary
> number of tweaks. For instance, EME takes 1 tweak per 512 bytes. If you
> have a 4k page to encrypt, you have to process 8 tweaks of whatever
> size.
> Therefore, you need 3 scatt
Am Mittwoch, den 09.02.2005, 17:19 -0800 schrieb Andrew Morton:
> > It must be
> > possible to process more than 2 mappings in softirq context.
>
> Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
> arbitrarily large number of them then no, we cannot do that.
>
> Possibl
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> It must be
> possible to process more than 2 mappings in softirq context.
Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
arbitrarily large number of them then no, we cannot do that.
Taking more than one sleeping kmap at a
On Wed, 2005-02-09 at 19:30 -0500, James Morris wrote:
> On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
>
> > I can't code for the case of two. Because, first, that's the idea of
> > generic in the name "generic scatterwalk", second, I need at least 3
> > scatterlists in parallel for LRW.
>
> Can y
On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
> I can't code for the case of two. Because, first, that's the idea of
> generic in the name "generic scatterwalk", second, I need at least 3
> scatterlists in parallel for LRW.
Can you explain why you need a third scatterlist for the LRW tweak?
My un
On Tue, 2005-02-08 at 19:09 -0500, James Morris wrote:
> On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
>
> > > You can't call kmap() in softirq context (why was it even trying?):
> >
> > Why not? What's the alternative, then?
>
> It can sleep in map_new_virtual().
>
> The alternative is to use a
On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
> > You can't call kmap() in softirq context (why was it even trying?):
>
> Why not? What's the alternative, then?
It can sleep in map_new_virtual().
The alternative is to use atomic kmaps. For this code, unless you can
point to something concrete
On Tue, 2005-02-08 at 18:30 -0500, James Morris wrote:
> On Tue, 8 Feb 2005, Fruhwirth Clemens wrote:
>
> > I shot out the last patch too quickly. Having reviewed the mapping one
> > more time I noticed, that there as the possibility of "off-by-one"
> > unmapping, and instead of doing doubtful gue
On Tue, 8 Feb 2005, Fruhwirth Clemens wrote:
> I shot out the last patch too quickly. Having reviewed the mapping one
> more time I noticed, that there as the possibility of "off-by-one"
> unmapping, and instead of doing doubtful guesses, if that's the case, I
> added a base pointer to scatter_wal
On Tue, 2005-02-08 at 17:08 +0100, Fruhwirth Clemens wrote:
> On Tue, 2005-02-08 at 09:48 -0500, James Morris wrote:
> > On Sat, 5 Feb 2005, Fruhwirth Clemens wrote:
> >
> > > + * The generic scatterwalker applies a certain function, pf, utilising
> > > + * an arbitrary number of scatterlist data a
On Tue, 2005-02-08 at 09:48 -0500, James Morris wrote:
> On Sat, 5 Feb 2005, Fruhwirth Clemens wrote:
>
> > + * The generic scatterwalker applies a certain function, pf, utilising
> > + * an arbitrary number of scatterlist data as it's arguments. These
> > + * arguments are supplied as an array of
On Sat, 5 Feb 2005, Fruhwirth Clemens wrote:
> Fixed formating and white-spaces. The biggest change is, that I stripped
> a redundant check from scatterwalk.c. This omission seems justified and
> shows no regression on my system. ( http://lkml.org/lkml/2005/2/3/87 )
> Can you give it a quick test
On Thu, 3 Feb 2005, Fruhwirth Clemens wrote:
> First attempt:
>
> static inline int scatterwalk_needscratch(struct scatter_walk *walk, int
> nbytes) {
>return ((nbytes) <= (walk)->len_this_page &&
>(((unsigned long)(walk)->data) & (PAGE_CACHE_SIZE - 1)) +
> (nbytes) <= PAG
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
> This code tests ok with IPSec, and delivers some good performance
> improvements. e.g. FTP transfers over transport mode AES over GigE sped
> up with this patch applied on one side of the connection by 20% for send
> and 15% for receive.
>
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
> On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
> > +#define scatterwalk_needscratch(walk, nbytes)
> > \
> > + ((nbytes) <= (walk)->len_this_page &&
> >
On Thu, 2005-02-03 at 13:40 +1300, Michal Ludvig wrote:
> Fruhwirth Clemens wrote:
>
> > Especially, if James ask me to redo Michal's conflicting patches
> > (done btw), which are totally off-topic for me.
>
> Great, thanks! Has the interface for multiblock modules changed or
> should my old m
Fruhwirth Clemens wrote:
> Especially, if James ask me to redo Michal's conflicting patches
> (done btw), which are totally off-topic for me.
Great, thanks! Has the interface for multiblock modules changed or
should my old modules work with it with no more effort?
Unfortulately I don't have a Pad
On Thu, 03 Feb 2005 01:21:35 +0100
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> I'm afraid, I'm not going to change it. I already lost too much time
> pushing LRW into the kernel.
The work has to be done by somebody. Linus would certainly reject any
attempt I would make to push code with that
On Wed, 2 Feb 2005, James Morris wrote:
> Correct, although I think this will get lost in the noise given that it's
> sitting in the middle of crypto processing. I'd remove it.
Dave just ok'd it, so take his advice over mine :-)
- james
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe
On Wed, 2005-02-02 at 15:34 -0800, David S. Miller wrote:
> Also, I think there will be objections to that studlyCaps naming you
> said your other code has. Keep garbage like that in the x11 sources,
> if you don't mind :-)
I'm afraid, I'm not going to change it. I already lost too much time
pus
On Thu, 3 Feb 2005, Fruhwirth Clemens wrote:
> > > +static int ecb_process_gw(void *_priv, int nsg, void **buf)
>
> > What does _gw mean?
>
> generic walker.. can be removed, if you like.
That's fine, was just wondering.
> > > + r = pf(priv, nsl, dispatch_list);
> > > + if(unl
On Thu, 03 Feb 2005 00:28:29 +0100
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> I suspected unlikely to be a hint for the compiler to do better jump
> prediction and speculations. Remove?
I don't think it hurts, keep it in there.
When the final patch is made with James's requested fixups, I'll
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
> On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
> > James, please test it against ipsec. I'm confident, that everything will
> > work as expected and we can proceed to merge padlock-multiblock against this
> > scatterwalker, so please Andrew, m
On Mon, 24 Jan 2005, Fruhwirth Clemens wrote:
> This patch adds the ability for a cipher mode to store cipher mode specific
> information in crypto_tfm. This is necessary for LRW's precomputed
> GF-multiplication tables.
This one looks fine as part of the LRW patchset (i.e. not needed for
generi
On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
> Ok, here comes a reworked scatterwalk patch. Instead of making
> scatterwalk_walk controllable via another additional function or interface,
> I decided to make scatterwalk_walk quickly restartable. Therefore, I had to
> move an initialization respon
On Sat, Jan 29, 2005 at 10:23:10AM -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > My advise is, drop Michaels patches
> > for now, merge scatterwalker and add an ability to change the stepsize
> > dynamically in the run. Then I will finish my port and post it.
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> My advise is, drop Michaels patches
> for now, merge scatterwalker and add an ability to change the stepsize
> dynamically in the run. Then I will finish my port and post it.
>
> If we can agree on this "agenda", I'll shift my focus to scatterwal
On Tue, 2005-01-25 at 10:52 -0500, James Morris wrote:
> On Mon, 24 Jan 2005, Andrew Morton wrote:
>
> > These patches clash badly with Michael Ludvig's work:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/cryptoapi-prepare-for-processin
On Tue, 25 Jan 2005, Fruhwirth Clemens wrote:
> The changes, I purposed, shouldn't be too hard to implement. I will
> build a skeleton for Michael, but I can't test the code, as I don't own
> a padlock system, further
I've got one now, and can use it for testing.
> I'm sorry to say but, my time
On Tue, 2005-01-25 at 10:52 -0500, James Morris wrote:
> I think the generic scatterwalk changes are more important and
> fundamental (still to be fully reviewed).
>
> I agree with Fruhwirth that the cipher code is starting to become
> ungainly. I'm not sure these patches are heading in the rig
On Mon, 24 Jan 2005, Andrew Morton wrote:
> These patches clash badly with Michael Ludvig's work:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/cryptoapi-prepare-for-processing-multiple-buffers-at.patch
> ftp://ftp.kernel.org/pub/linux/kern
On Mon, 2005-01-24 at 14:31 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > This patch adds the ability for a cipher mode to store cipher mode specific
> > information in crypto_tfm. This is necessary for LRW's precomputed
> > GF-multiplication tables.
>
> These
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> This patch adds the ability for a cipher mode to store cipher mode specific
> information in crypto_tfm. This is necessary for LRW's precomputed
> GF-multiplication tables.
These patches clash badly with Michael Ludvig's work:
ftp://ftp.kernel.org/
I'll review this in detail over the next day or so (still catching up on
some backlog after vacation).
Just wondering how much testing the generic scatterwalk code has had (I
gather disk encryption has been tested, but what about ipsec?).
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To un
50 matches
Mail list logo
