search for: p_idx

I would like to use the 'tryCatch' function but am having a hard time getting my head around it. In 'C' like languages try/catch/finally means try a block of statements and if any throw an error then do the statements in the catch block and then error or not always do the staements in the finally block. In 'R' as best as I can tell the block of staements in the try block is

Hi all, this series adds multiqueue support to the virtio-scsi driver, based on Jason Wang's work on virtio-net. It uses a simple queue steering algorithm that expects one queue per CPU. LUNs in the same target always use the same queue (so that commands are not reordered); queue switching occurs when the request being queued is the only one for the target. Also based on Jason's

Hi all, this series adds multiqueue support to the virtio-scsi driver, based on Jason Wang's work on virtio-net. It uses a simple queue steering algorithm that expects one queue per CPU. LUNs in the same target always use the same queue (so that commands are not reordered); queue switching occurs when the request being queued is the only one for the target. Also based on Jason's

OK, this is (ab)uses some of Paolo's patches. The first 7 are candidates for this merge window (maybe), the rest I'm not so sure about. Thanks, Rusty. Paolo Bonzini (3): scatterlist: introduce sg_unmark_end virtio-blk: reorganize virtblk_add_req virtio-blk: use virtqueue_add_sgs on req path Rusty Russell (13): virtio_ring: virtqueue_add_sgs, to add multiple sgs. virtio-blk:

OK, this is (ab)uses some of Paolo's patches. The first 7 are candidates for this merge window (maybe), the rest I'm not so sure about. Thanks, Rusty. Paolo Bonzini (3): scatterlist: introduce sg_unmark_end virtio-blk: reorganize virtblk_add_req virtio-blk: use virtqueue_add_sgs on req path Rusty Russell (13): virtio_ring: virtqueue_add_sgs, to add multiple sgs. virtio-blk:

The virtqueue_add_buf function has two limitations: 1) it requires the caller to provide all the buffers in a single call; 2) it does not support chained scatterlists: the buffers must be provided as an array of struct scatterlist. Because of these limitations, virtio-scsi has to copy each request into a scatterlist internal to the driver. It cannot just use the one that was prepared by the

The virtqueue_add_buf function has two limitations: 1) it requires the caller to provide all the buffers in a single call; 2) it does not support chained scatterlists: the buffers must be provided as an array of struct scatterlist. Because of these limitations, virtio-scsi has to copy each request into a scatterlist internal to the driver. It cannot just use the one that was prepared by the

Most device drivers do not need to perform any postprocessing on the scatterlists they receive from higher-level drivers (e.g. the block or SCSI layer), because they translate the request metadata directly from the various C structs into the data that is required by the device. virtio devices however do this translation in two steps: a device-specific step in the device driver, and generic

Most device drivers do not need to perform any postprocessing on the scatterlists they receive from higher-level drivers (e.g. the block or SCSI layer), because they translate the request metadata directly from the various C structs into the data that is required by the device. virtio devices however do this translation in two steps: a device-specific step in the device driver, and generic

Add virtqueue_add_sgs which is more general than virtqueue_add_buf, which makes virtio-scsi and virtio-blk nicer, then add virtqueue_add_inbuf and virtqueue_add_outbuf which handle the more general case, and finally delete virtqueue_add_buf(). I'm hoping this will be the final post of the whole series, and it can move from my pending-rebases tree into virtio-next. Thanks! Rusty. Paolo

Add virtqueue_add_sgs which is more general than virtqueue_add_buf, which makes virtio-scsi and virtio-blk nicer, then add virtqueue_add_inbuf and virtqueue_add_outbuf which handle the more general case, and finally delete virtqueue_add_buf(). I'm hoping this will be the final post of the whole series, and it can move from my pending-rebases tree into virtio-next. Thanks! Rusty. Paolo

...tqueue_add_buf(vscsi->event_vq.vq, &sg, 0, 1, event_node, + err = virtqueue_add_buf(vscsi->event_vq.vq, NULL, &sg, event_node, GFP_ATOMIC); if (!err) virtqueue_kick(vscsi->event_vq.vq); @@ -378,7 +378,7 @@ static void virtscsi_map_sgl(struct scatterlist *sg, unsigned int *p_idx, */ static void virtscsi_map_cmd(struct virtio_scsi_target_state *tgt, struct virtio_scsi_cmd *cmd, - unsigned *out_num, unsigned *in_num, + unsigned *out, unsigned *in, size_t req_size, size_t resp_size) { struct scsi_cmnd *sc = cmd->sc; @@ -392,7 +392,7 @@...

...tqueue_add_buf(vscsi->event_vq.vq, &sg, 0, 1, event_node, + err = virtqueue_add_buf(vscsi->event_vq.vq, NULL, &sg, event_node, GFP_ATOMIC); if (!err) virtqueue_kick(vscsi->event_vq.vq); @@ -378,7 +378,7 @@ static void virtscsi_map_sgl(struct scatterlist *sg, unsigned int *p_idx, */ static void virtscsi_map_cmd(struct virtio_scsi_target_state *tgt, struct virtio_scsi_cmd *cmd, - unsigned *out_num, unsigned *in_num, + unsigned *out, unsigned *in, size_t req_size, size_t resp_size) { struct scsi_cmnd *sc = cmd->sc; @@ -392,7 +392,7 @@...