linux-kernel - Re: [PATCH 0/2]: Remote softirq invocation infrastructure.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080922135440.GC9549@secunet.com>
Date:	Mon, 22 Sep 2008 15:54:40 +0200
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	David Miller <davem@...emloft.net>, dwalker@...sta.com,
	arjan@...radead.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, jens.axboe@...cle.com
Subject: Re: [PATCH 0/2]: Remote softirq invocation infrastructure.

On Mon, Sep 22, 2008 at 04:23:09PM +0800, Herbert Xu wrote:
> 
> > With my test environment (two quad core boxes) I get with IPSEC
> > aes192-sha1 and one tcp stream a throughput of about 600 Mbit/s
> > compared to about 200 Mbit/s without the parallel processing. 
> 
> Yes this would definitely help IPsec.  However, I'm not so sure
> of its benefit to routing and other parts of networking.  That's
> why I'd rather have this sort of hack stay in the crypto system
> where it's isolated rather than having it proliferate throughout
> the network stack.

The crypto benefits the most of course, but routing and xfrm lookups
could benefit on bigger networks too. However, the method to bring
the packets back to order is quite generic and could be used
even in the crypto system. The important thing for me is that we
can run in parallel even if we have just one flow.

> 
> When the time comes to weed out this because all CPUs that matter
> have encryption in hardware then it'll be much easier to delete a
> crypto algorithm as opposed to removing parts of the network
> infrastructure :)
> 

Yes, if you think about how to remove it I agree here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/