On Tue, Jul 29, 2014 at 03:28:25PM -0700, Tim Chen wrote:
Peter,
Is my explanation adequate or you still have objection to the implementation?
I'm
trying to decide here whether to extend our batch processing by
the crypto daemon (prolong our busy period)
based on whether there are other
On Fri, 2014-07-25 at 09:25 -0700, Tim Chen wrote:
On Fri, 2014-07-25 at 09:08 +0200, Peter Zijlstra wrote:
On Tue, Jul 22, 2014 at 03:09:32PM -0700, Tim Chen wrote:
+/* Called in workqueue context, do one real cryption work (via
+ * req-complete) and reschedule itself if there are more
On Tue, Jul 22, 2014 at 03:09:32PM -0700, Tim Chen wrote:
+/* Called in workqueue context, do one real cryption work (via
+ * req-complete) and reschedule itself if there are more work to
+ * do. */
You seem to manage the 'normal' comment style in other places, this one
'special' for a reason?
On Tue, Jul 22, 2014 at 03:09:32PM -0700, Tim Chen wrote:
This patch introduces the multi-buffer crypto daemon which is responsible
for submitting crypto jobs in a work queue to the responsible multi-buffer
crypto algorithm. The idea of the multi-buffer algorihtm is to put
data streams from
On Fri, 2014-07-25 at 09:08 +0200, Peter Zijlstra wrote:
On Tue, Jul 22, 2014 at 03:09:32PM -0700, Tim Chen wrote:
+/* Called in workqueue context, do one real cryption work (via
+ * req-complete) and reschedule itself if there are more work to
+ * do. */
You seem to manage the 'normal'
On Fri, 2014-07-25 at 09:26 +0200, Peter Zijlstra wrote:
On Tue, Jul 22, 2014 at 03:09:32PM -0700, Tim Chen wrote:
This patch introduces the multi-buffer crypto daemon which is responsible
for submitting crypto jobs in a work queue to the responsible multi-buffer
crypto algorithm. The idea
This patch introduces the multi-buffer crypto daemon which is responsible
for submitting crypto jobs in a work queue to the responsible multi-buffer
crypto algorithm. The idea of the multi-buffer algorihtm is to put
data streams from multiple jobs in a wide (AVX2) register and then
take advantage
