* Herbert Xu | 2007-07-12 16:03:55 [+0800]: >Sebastian Siewior <bigeasy@xxxxxxxxxxxxx> wrote: >> >> Limit means you want me to drop requests after a certain limit (i.e. >> when my queue is full)? > >Yep, there's no point in holding onto lots of requests if the >hardware simply can't catch up. Makes sense. >> I would have to start an extra thread that removes requests from >> crypto_enqueue_request and enqueues them into kspu_enqueue_work_item. > >I'm probably missing something but why couldn't you pull the requests >from crypto_enqueue_request in the same place where you pull requests >currently? In other words couldn't you just pull both queues? I used your crypto_enqueue_request in first place and decided against because it got a little too complex for me: If I enqueue directly on a SPU from crypto_enqueue_request than it means that every non-process context user must implement a thread for doing this. Additionally I must add locks to ensure that two different users are not writing requests at the same time. After the request has been written to the SPU I have to start the SPU (kick off a thread). And now little more complex. Before the SPU can be switched on, I must make sure that atleast a specific amout of requests is in queue and fill up if necessary (here is allready my second user). For doing this I must hold the same locks (same like for enqueue on SPU) so I must either unlock them and regain the locks again or duplicate some code. Right now, all the implementation specific details are taken care of my KSPU implementation. There are no locks required (except that one SPU specifc lock which must be hold anyway) because KSPU is the only part of the code that may write the requests. Once the request is written to the SPU, the SPU can be started immediately (if it is not running allready what is known). >Cheers, Cheers, Sebastian - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
