search for: dataqueue

...> + unsigned int len; > + struct ablkcipher_request *ablk_req; > + int error; > + > + spin_lock_irqsave(&vcrypto->lock, flags); Would it make sense to use a per virtqueue lock like in virtio_blk for example instead of locking on the whole device? OK, it seems you use only one dataqueue, so it may not be that relevant. > + do { > + virtqueue_disable_cb(vq); > + while ((vc_req = virtqueue_get_buf(vq, &len)) != NULL) { > + if (vc_req->type == VIRTIO_CRYPTO_SYM_OP_CIPHER) { > + switch (vc_req->status) { > + case VIRTIO_CRYPTO_OK: > + erro...

...> + unsigned int len; > + struct ablkcipher_request *ablk_req; > + int error; > + > + spin_lock_irqsave(&vcrypto->lock, flags); Would it make sense to use a per virtqueue lock like in virtio_blk for example instead of locking on the whole device? OK, it seems you use only one dataqueue, so it may not be that relevant. > + do { > + virtqueue_disable_cb(vq); > + while ((vc_req = virtqueue_get_buf(vq, &len)) != NULL) { > + if (vc_req->type == VIRTIO_CRYPTO_SYM_OP_CIPHER) { > + switch (vc_req->status) { > + case VIRTIO_CRYPTO_OK: > + erro...

...< > > + int error; < > > + < > > + spin_lock_irqsave(&vcrypto->lock, flags); < > < > Would it make sense to use a per virtqueue lock < > like in virtio_blk for example instead of locking on the whole < > device? OK, it seems you use only one dataqueue, so it < > may not be that relevant. < > < Currently yes, both the backend device (cryptodev-backend-builtin) < and the frontend driver use one dataqueue. < I think it makes sense to use per virtqueue lock here though it only uses one queue so far, but in the spec we already...

...< > > + int error; < > > + < > > + spin_lock_irqsave(&vcrypto->lock, flags); < > < > Would it make sense to use a per virtqueue lock < > like in virtio_blk for example instead of locking on the whole < > device? OK, it seems you use only one dataqueue, so it < > may not be that relevant. < > < Currently yes, both the backend device (cryptodev-backend-builtin) < and the frontend driver use one dataqueue. < I think it makes sense to use per virtqueue lock here though it only uses one queue so far, but in the spec we already...

...> < > > + spin_lock_irqsave(&vcrypto->lock, flags); > > < > > > < > Would it make sense to use a per virtqueue lock > > < > like in virtio_blk for example instead of locking on the whole > > < > device? OK, it seems you use only one dataqueue, so it > > < > may not be that relevant. > > < > > > < Currently yes, both the backend device (cryptodev-backend-builtin) > > < and the frontend driver use one dataqueue. > > < > > > > I think it makes sense to use per virtqueue lock h...

...> < > > + spin_lock_irqsave(&vcrypto->lock, flags); > > < > > > < > Would it make sense to use a per virtqueue lock > > < > like in virtio_blk for example instead of locking on the whole > > < > device? OK, it seems you use only one dataqueue, so it > > < > may not be that relevant. > > < > > > < Currently yes, both the backend device (cryptodev-backend-builtin) > > < and the frontend driver use one dataqueue. > > < > > > > I think it makes sense to use per virtqueue lock h...

...uct ablkcipher_request *ablk_req; > > + int error; > > + > > + spin_lock_irqsave(&vcrypto->lock, flags); > > Would it make sense to use a per virtqueue lock > like in virtio_blk for example instead of locking on the whole > device? OK, it seems you use only one dataqueue, so it > may not be that relevant. > Currently yes, both the backend device (cryptodev-backend-builtin) and the frontend driver use one dataqueue. Regards, -Gonglei

...t; < > > + > < > > + spin_lock_irqsave(&vcrypto->lock, flags); > < > > < > Would it make sense to use a per virtqueue lock > < > like in virtio_blk for example instead of locking on the whole > < > device? OK, it seems you use only one dataqueue, so it > < > may not be that relevant. > < > > < Currently yes, both the backend device (cryptodev-backend-builtin) > < and the frontend driver use one dataqueue. > < > > I think it makes sense to use per virtqueue lock here though it only uses one > qu...

...>>> > > + /* Pad ctrl header */ >>> > > + vcrypto->ctrl.header.opcode = >>> > > + cpu_to_le32(VIRTIO_CRYPTO_CIPHER_CREATE_SESSION); >>> > > + vcrypto->ctrl.header.algo = cpu_to_le32(alg); >>> > > + /* Set the default dataqueue id to 0 */ >>> > > + vcrypto->ctrl.header.queue_id = 0; >>> > > + >>> > > + vcrypto->input.status = cpu_to_le32(VIRTIO_CRYPTO_ERR); >>> > > + /* Pad cipher's parameters */ >>> > > + vcrypto->ctrl.u.sym_create_se...

...>>> > > + /* Pad ctrl header */ >>> > > + vcrypto->ctrl.header.opcode = >>> > > + cpu_to_le32(VIRTIO_CRYPTO_CIPHER_CREATE_SESSION); >>> > > + vcrypto->ctrl.header.algo = cpu_to_le32(alg); >>> > > + /* Set the default dataqueue id to 0 */ >>> > > + vcrypto->ctrl.header.queue_id = 0; >>> > > + >>> > > + vcrypto->input.status = cpu_to_le32(VIRTIO_CRYPTO_ERR); >>> > > + /* Pad cipher's parameters */ >>> > > + vcrypto->ctrl.u.sym_create_se...

...num_in = 0; > + > + memset(&ctrl, 0, sizeof(ctrl)); > + memset(&input, 0, sizeof(input)); > + /* Pad ctrl header */ > + ctrl.header.opcode = > cpu_to_le32(VIRTIO_CRYPTO_CIPHER_CREATE_SESSION); > + ctrl.header.algo = cpu_to_le32((uint32_t)alg); > + /* Set the default dataqueue id to 0 */ > + ctrl.header.queue_id = 0; > + > + input.status = cpu_to_le32(VIRTIO_CRYPTO_ERR); > + /* Pad cipher's parameters */ > + ctrl.u.sym_create_session.op_type = > + cpu_to_le32(VIRTIO_CRYPTO_SYM_OP_CIPHER); > + ctrl.u.sym_create_session.u.cipher.para.algo = ctrl.h...

...to a node with no memory + * there is no point in using the accelerator since the remote + * memory transaction will be very slow. + */ + dev_err(&vdev->dev, "Invalid NUMA configuration.\n"); + return -EINVAL; + } + + virtio_cread(vdev, struct virtio_crypto_config, + max_dataqueues, &max_data_queues); + if (max_data_queues < 1) + max_data_queues = 1; + + dev_info(&vdev->dev, "max_queues: %u\n", max_data_queues); + + virtio_cread(vdev, struct virtio_crypto_config, + max_cipher_key_len, &max_cipher_key_len); + virtio_cread(vdev, struct virtio_cr...

...to a node with no memory + * there is no point in using the accelerator since the remote + * memory transaction will be very slow. + */ + dev_err(&vdev->dev, "Invalid NUMA configuration.\n"); + return -EINVAL; + } + + virtio_cread(vdev, struct virtio_crypto_config, + max_dataqueues, &max_data_queues); + if (max_data_queues < 1) + max_data_queues = 1; + + dev_info(&vdev->dev, "max_queues: %u\n", max_data_queues); + + virtio_cread(vdev, struct virtio_crypto_config, + max_cipher_key_len, &max_cipher_key_len); + virtio_cread(vdev, struct virtio_cr...

v7: - fix "BUG: smp_processor_id() in preemptible [00000000] code" reported by Halil, using get_cpu/put_cpu instead of calling smp_processor_id() directly. - fix a possible spinlock recursion in virtcrypto_dataq_callback(), we should release the spinlock before invoking the callback. - rebase on the latest kernel master tree. v6: - add patch 1/2 to make sparc architecture

v7: - fix "BUG: smp_processor_id() in preemptible [00000000] code" reported by Halil, using get_cpu/put_cpu instead of calling smp_processor_id() directly. - fix a possible spinlock recursion in virtcrypto_dataq_callback(), we should release the spinlock before invoking the callback. - rebase on the latest kernel master tree. v6: - add patch 1/2 to make sparc architecture

...valid NUMA configuration.\n"); > + return -EINVAL; > + } > + > + vcrypto = kzalloc_node(sizeof(*vcrypto), GFP_KERNEL, > + dev_to_node(&vdev->dev)); > + if (!vcrypto) > + return -ENOMEM; > + > + virtio_cread(vdev, struct virtio_crypto_config, > + max_dataqueues, &max_data_queues); > + if (max_data_queues < 1) > + max_data_queues = 1; > + > + virtio_cread(vdev, struct virtio_crypto_config, > + max_cipher_key_len, &max_cipher_key_len); > + virtio_cread(vdev, struct virtio_crypto_config, > + max_auth_key_len, &max_auth...

...valid NUMA configuration.\n"); > + return -EINVAL; > + } > + > + vcrypto = kzalloc_node(sizeof(*vcrypto), GFP_KERNEL, > + dev_to_node(&vdev->dev)); > + if (!vcrypto) > + return -ENOMEM; > + > + virtio_cread(vdev, struct virtio_crypto_config, > + max_dataqueues, &max_data_queues); > + if (max_data_queues < 1) > + max_data_queues = 1; > + > + virtio_cread(vdev, struct virtio_crypto_config, > + max_cipher_key_len, &max_cipher_key_len); > + virtio_cread(vdev, struct virtio_crypto_config, > + max_auth_key_len, &max_auth...

...> + return -EINVAL; > + } > + > + vcrypto = kzalloc_node(sizeof(*vcrypto), GFP_KERNEL, > + dev_to_node(&vdev->dev)); > + if (!vcrypto) > + return -ENOMEM; > + > + max_data_queues_le = virtio_cread32_le(vdev, > + offsetof(struct virtio_crypto_config, max_dataqueues)); > + vcrypto->max_data_queues = le32_to_cpu(max_data_queues_le); > + if (vcrypto->max_data_queues < 1) > + vcrypto->max_data_queues = 1; > + > + dev_info(&vdev->dev, "max_queues: %u\n", vcrypto->max_data_queues); > + > + max_cipher_key_len_le...

...> + return -EINVAL; > + } > + > + vcrypto = kzalloc_node(sizeof(*vcrypto), GFP_KERNEL, > + dev_to_node(&vdev->dev)); > + if (!vcrypto) > + return -ENOMEM; > + > + max_data_queues_le = virtio_cread32_le(vdev, > + offsetof(struct virtio_crypto_config, max_dataqueues)); > + vcrypto->max_data_queues = le32_to_cpu(max_data_queues_le); > + if (vcrypto->max_data_queues < 1) > + vcrypto->max_data_queues = 1; > + > + dev_info(&vdev->dev, "max_queues: %u\n", vcrypto->max_data_queues); > + > + max_cipher_key_len_le...

...gt; + > > + vcrypto = kzalloc_node(sizeof(*vcrypto), GFP_KERNEL, > > + dev_to_node(&vdev->dev)); > > + if (!vcrypto) > > + return -ENOMEM; > > + > > + max_data_queues_le = virtio_cread32_le(vdev, > > + offsetof(struct virtio_crypto_config, max_dataqueues)); > > + vcrypto->max_data_queues = le32_to_cpu(max_data_queues_le); > > + if (vcrypto->max_data_queues < 1) > > + vcrypto->max_data_queues = 1; > > + > > + dev_info(&vdev->dev, "max_queues: %u\n", vcrypto->max_data_queues); > >...