On Mon, Jan 24, 2011 at 2:54 PM, Phil Sutter <phil.sut...@viprinet.com> wrote: > Hey Nikos, >> 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.
> 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...). regards, Nikos _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
