search for: this_id

On Tue, Mar 10, 2020 at 09:08:56PM +0000, John Garry wrote: > On 10/03/2020 18:32, Christoph Hellwig wrote: > > On Wed, Mar 11, 2020 at 12:25:28AM +0800, John Garry wrote: > > > From: Hannes Reinecke <hare at suse.com> > > > > > > Allocate a separate 'reserved_cmd_q' for sending reserved commands. > > > > Why? Reserved command

On Tue, Mar 10, 2020 at 09:08:56PM +0000, John Garry wrote: > On 10/03/2020 18:32, Christoph Hellwig wrote: > > On Wed, Mar 11, 2020 at 12:25:28AM +0800, John Garry wrote: > > > From: Hannes Reinecke <hare at suse.com> > > > > > > Allocate a separate 'reserved_cmd_q' for sending reserved commands. > > > > Why? Reserved command

On 4/7/20 4:35 PM, John Garry wrote: > On 07/04/2020 15:00, Hannes Reinecke wrote: >> On 4/7/20 1:54 PM, John Garry wrote: >>> On 06/04/2020 10:05, Hannes Reinecke wrote: [ .. ] >>>> This would be okay if 'this_id' would have been defined by the driver; >>>> sadly, most drivers which are affected here do set 'this_id' to -1. >>>> So we wouldn't have a nice target ID to allocate the device from, let >>>> alone the problem that we would have to emulate a comp...

...erface to use a tag for a host wide command vs >>> introducing a parallel path. >>> >> Thinking about it some more, I don't think that scsi_get_host_dev() is >> the best way of handling it. >> Problem is that it'll create a new scsi_device with <hostno:this_id:0>, >> which will then show up via eg 'lsscsi'. > > are you sure? Doesn't this function just allocate the sdev, but do > nothing with it, like probing it? > > I bludgeoned it in here for PoC: > > https://github.com/hisilicon/kernel-dev/commit/ef0ae85408...

See if I can stir up a little life with a demo. I can''t believe that Ajax.Autocomplete doesn''t work on IE, so I *must* be doing something wrong. Trying to figure this out I added some alerts to control.js and it seems that IE is not getting the onkeypress events. So, here''s a demo: http://hank.org/demos/form.html That contains two fields with onkeypress events:

...00:10PM +0200, Hannes Reinecke wrote: >>> My concern is this: >>> >>> struct scsi_device *scsi_get_host_dev(struct Scsi_Host *shost) >>> { >>> ????[ .. ] >>> ????starget = scsi_alloc_target(&shost->shost_gendev, 0, >>> shost->this_id); >>> ????[ .. ] >>> >>> and we have typically: >>> >>> drivers/scsi/hisi_sas/hisi_sas_v3_hw.c: .this_id??????????????? = -1, >>> >>> It's _very_ uncommon to have a negative number as the SCSI target >>> device; in >&gt...

...PNOTSUPP; + } + + return sdev->queue_depth; +} + static int virtscsi_abort(struct scsi_cmnd *sc) { struct virtio_scsi *vscsi = shost_priv(sc->device->host); @@ -684,6 +715,7 @@ static struct scsi_host_template virtscsi_host_template_single = { .proc_name = "virtio_scsi", .this_id = -1, .queuecommand = virtscsi_queuecommand_single, + .change_queue_depth = virtscsi_change_queue_depth, .eh_abort_handler = virtscsi_abort, .eh_device_reset_handler = virtscsi_device_reset, @@ -700,6 +732,7 @@ static struct scsi_host_template virtscsi_host_template_multi = { .proc_name =...

...PNOTSUPP; + } + + return sdev->queue_depth; +} + static int virtscsi_abort(struct scsi_cmnd *sc) { struct virtio_scsi *vscsi = shost_priv(sc->device->host); @@ -684,6 +715,7 @@ static struct scsi_host_template virtscsi_host_template_single = { .proc_name = "virtio_scsi", .this_id = -1, .queuecommand = virtscsi_queuecommand_single, + .change_queue_depth = virtscsi_change_queue_depth, .eh_abort_handler = virtscsi_abort, .eh_device_reset_handler = virtscsi_device_reset, @@ -700,6 +732,7 @@ static struct scsi_host_template virtscsi_host_template_multi = { .proc_name =...

On Wed, Mar 11, 2020 at 12:25:27AM +0800, John Garry wrote: > From: Hannes Reinecke <hare at suse.com> > > Add a new field 'nr_reserved_cmds' to the SCSI host template to > instruct the block layer to set aside a tag space for reserved > commands. > > Signed-off-by: Hannes Reinecke <hare at suse.com> > --- > drivers/scsi/scsi_lib.c | 1 + >

On Wed, Mar 11, 2020 at 12:25:27AM +0800, John Garry wrote: > From: Hannes Reinecke <hare at suse.com> > > Add a new field 'nr_reserved_cmds' to the SCSI host template to > instruct the block layer to set aside a tag space for reserved > commands. > > Signed-off-by: Hannes Reinecke <hare at suse.com> > --- > drivers/scsi/scsi_lib.c | 1 + >

...int hpsa_scsi_host_alloc(struct ctlr_info *h) { struct Scsi_Host *sh; sh = scsi_host_alloc(&hpsa_driver_template, sizeof(h)); if (sh == NULL) { dev_err(&h->pdev->dev, "scsi_host_alloc failed\n"); return -ENOMEM; } sh->io_port = 0; sh->n_io_port = 0; sh->this_id = -1; sh->max_channel = 3; sh->max_cmd_len = MAX_COMMAND_SIZE; sh->max_lun = HPSA_MAX_LUN; sh->max_id = HPSA_MAX_LUN; sh->can_queue = h->nr_cmds - HPSA_NRESERVED_CMDS; sh->cmd_per_lun = sh->can_queue; So the idea of this patchset is to convert existing use-cases; seei...

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). The patches build on top of the new virtio APIs at http://permalink.gmane.org/gmane.linux.kernel.virtualization/18431; the new API simplifies the locking of the virtio-scsi driver nicely, thus it makes sense to require them as a prerequisite.

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). The patches build on top of the new virtio APIs at http://permalink.gmane.org/gmane.linux.kernel.virtualization/18431; the new API simplifies the locking of the virtio-scsi driver nicely, thus it makes sense to require them as a prerequisite.

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). This version rebased on Rusty's virtio ring rework patches. We hope this can go into virtio-next together with the virtio ring rework pathes. V5: improving the grammar of 1/5 (Paolo) move the dropping of sg_elems to 'virtio-scsi: use

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). This version rebased on Rusty's virtio ring rework patches. We hope this can go into virtio-next together with the virtio ring rework pathes. V5: improving the grammar of 1/5 (Paolo) move the dropping of sg_elems to 'virtio-scsi: use

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). This version rebased on Rusty's virtio ring rework patches. We hope this can go into virtio-next together with the virtio ring rework pathes. V4: rebase on virtio ring rework patches (rusty's pending-rebases branch) V3 and be found

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). This version rebased on Rusty's virtio ring rework patches. We hope this can go into virtio-next together with the virtio ring rework pathes. V4: rebase on virtio ring rework patches (rusty's pending-rebases branch) V3 and be found

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). This version rebased on Rusty's virtio ring rework patches, which has already gone into virtio-next today. We hope this can go into virtio-next together with the virtio ring rework pathes. V6: rework "redo allocation of target data"

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). This version rebased on Rusty's virtio ring rework patches, which has already gone into virtio-next today. We hope this can go into virtio-next together with the virtio ring rework pathes. V6: rework "redo allocation of target data"

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). This version rebased on Rusty's virtio ring rework patches, which has already gone into virtio-next today. We hope this can go into virtio-next together with the virtio ring rework pathes. V7: respin to fix the patch apply error V6: rework