[Cbe-oss-dev] [RFC 4/5] spufs: add kernel support for spu task
Benjamin Herrenschmidt
benh at kernel.crashing.org
Wed Jun 13 07:51:15 EST 2007
On Tue, 2007-06-12 at 18:10 +0200, Sebastian Siewior wrote:
> plain text document attachment (spufs-add_kernel_spu_support.diff)
> Utilisation of SPUs by the kernel, main implementation.
> The idea behind this implemtation is that there are single jobs that are
> executed asynchronous on the SPU. The user queues jobs with
> enqueue_for_spu() and gets a callback once the job is completed. The
> function itself does not block, it returns -EINPROGRESS.
Why would a funtion return a negative error code as its normal return
value ? If the name of the function is "enqueue", I would expect it to
do just that, not wait, anyway, and thus return 0 on success.
> The job will be
> queued in a linked list (protected by a spinlock, calls from softirq
> context are possible) and the kthread that handles the SPU will be woken
> up.
> The SPU thread takes the first element from the list, and calls the
> enqueue function supplied by the user. The user has now the chance to fill
> the ring buffer entry and set a callback for notification which will be
> called once the SPU code accomplished the task.
> User's enqueue function may put more than one work item on the SPU if it
> is necessary. However the KSPU code ensures only one free slot. If more
> slots are needed, kspu may not dequeue the request from the queue and will
> call again, once another slot is available (user's enqueue function has to
> notice this of course).
So you create one SPU "kernel" context ? Why not one per SPU ?
Ben.
More information about the cbe-oss-dev
mailing list