Hi, On Tue, Jan 25, 2011 at 01:29:37PM +0100, Nikos Mavrogiannopoulos wrote: > >> I have applied up to here... This is an interesting patch, but I'm > >> more curious on how you use it in practice? Is to load balance > >> across CPUs? If this is the purpose shouldn't it be implicit > >> and only handled by the driver? Is there a reason to have the > >> CPU to use explicit? > > We use cryptodev to accelerate TLS connections in userspace. The > > particular hardware is an Intel Core i5, so the crypto engine in > > question actually consists of some optimised instructions, executed on > > the CPU itself. > Well on this particular CPU you could use user-space crypto directly, > that will avoid the context-switching to kernel. You would not have the > asynchronous operation though.
Yes, of course. For CPU-internal crypto accelerators there is always the alternative to just implement everything in userspace. But we also have hardware with a real, asynchronous crypto engine and want to keep the common interface. > > My patch allows for specifying the CPU hash_n_crypt (for async calls, of > > course) should run on. When the calling application is using a lot of > > CPU cycles, it may be desirable to have the crypto stuff run on another > > CPU (despite the worse cache use then). > > I don't see where the crypto API provides such a feature. Do you see any > > better way of implementing this (other than dedicating a CPU-bound > > thread in userspace for cryptodev communication)? > > I'm don't know much on scheduling, but just an idea, what about avoiding the > userspace hint for cpu with a scheduler that evenly distributes jobs across > all > available CPUs - by checking the amount of pending jobs on each one, and > submitting to the one with the lowest number of jobs? This will favor the idle > ones as they will complete their jobs earlier than any busy one, and thus will > accept more jobs? Any other ideas on such a scheduler? (I prefer the idea > of an internal scheduler to provide benefit of smp to all applications without > having to directly specify a cpu...). Well, that's definitely a noble way to go. But remember, we'd have to implement this on our own - at least I didn't find a way to have the workqueue dispatch jobs to a set of CPUs rather than just a single one (even that is quite hacky, since cryptodev should make sure the specified CPU doesn't go away (CPU-hotplugging), which it actually doesn't for now). Implementations aside, possible out-of-order completion of the scheduled jobs seems like a bigger design-problem to me with this approach. As I didn't implement any "transaction ID" for retrieving specific asynchronous jobs, things will get quite messy if the jobs' sequence is not assured any more. Because of the internal design though, it's not impossible to keep the ordering - but you'd get situations where e.g. jobs 3, 4 and 5 are already finished, but job 2 needs to finish before all can be retrieved by the user. IOW, being hit by the full mess of parallel algorithms. ;) Please don't get me wrong here - I really like your idea of scheduling jobs internally to different CPUs (which is probably better than the kernel's default of binding all to the caller's CPU for cache lookup improvements). But I doubt the effort is worth the better handling of these few CPU-internal crypto engines on SMP systems. So I guess what's clear now is that this feature will hardly ever find use, so I'm not too curious anymore about getting it upstream. I guess that puts the ball into your hands - effectively you're the one who has to decide if there is any use for this feature (other than just mine, of course), and if yes, how that should be implemented. I just went the least intrusive way that still fulfils my employer's requirements. Greetings (and sorry for the flood), Phil -- ********************************************** Viprinet auf der CeBIT 2011 – 1.-5. März: Besuchen Sie uns in Halle 13, Stand D19. Alle Produkte im Livebetrieb, zahlreiche Beispielapplikationen. Besuchen Sie uns! Gerne schicken wir Ihnen kostenlose Eintrittskarten. ********************************************** Visit us at CeBIT 2011, March 1 to 5 in Hannover, Germany. Hall 13, Booth D19. ********************************************** Viprinet GmbH Mainzer Str. 43 55411 Bingen am Rhein Germany Zentrale: +49-6721-49030-0 Durchwahl: +49-6721-49030-134 Fax: +49-6721-49030-209 phil.sut...@viprinet.com http://www.viprinet.com Sitz der Gesellschaft: Bingen am Rhein Handelsregister: Amtsgericht Mainz HRB40380 Geschäftsführer: Simon Kissel _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
