From: Christoph Hellwig <hch@lst.de> To: Mike Snitzer <snitzer@redhat.com> Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@fb.com>, linux-block@vger.kernel.org, dm-devel@redhat.com, linux-scsi@vger.kernel.org Subject: Re: [PATCH 05/15] dm: remove incomple BLOCK_PC support Date: Fri, 13 Jan 2017 09:14:16 +0100 [thread overview] Message-ID: <20170113081416.GA26337@lst.de> (raw) In-Reply-To: <20170112222845.GA25349@redhat.com> On Thu, Jan 12, 2017 at 05:28:45PM -0500, Mike Snitzer wrote: > What is "incomplete" about request-based DM's BLOCK_PC support? BLOCK_PC requests are always aomething issued by the driver itself (for a broad defintion of the driver, aka everything under the block layer that works together is a driver for this purpose, e.g. all of the SCSI subsystem). If a driver doesn't issue BLOCK_PC requests itself or through library functions only called from the driver (e.g. scsi_cmd_ioctl) it is incomplete because it can't be used. > I'm also missing how you're saying the new blk-mq request-based DM will > work with your new model. I appreciate that we get the request from the > underlying blk-mq request_queue and it'll be properly sized. But > wouldn't we need to pass data back up for these SCSI pass-through > requests? So wouldn't the top-level multipath request_queue need to > setup cmd_size? As said above - supporting BLOCK_PC for dm does not make sense, as it's an internal passthrough mechanism for driver internal use. It just happened we standardized it at the block layer because SCSI commands are a standard supported by a few different drivers, e.g. SCSI itself, the old ide code for ATAPI and CCISS and virtio_blk which primarily are block drivers but allow some SCSI passthrough. To be honest I'd love to just fold BLOCK_PC into the SCSI layer sooner or later - the old IDE code and CCISS should die off sooner or later, and virtio_blk scsi passthrough was a horrible idea to start with (and I say that as the person who had the idea back then and implemented it..) > Sorry for the naive questions (that clearly speak to me not > understanding how this aspect of the block and SCSI code work).. but I'd > like to understand where DM will be lacking going forward. At least in terms of BLOCK_PC nothing will change for dm, the code was simply dead on arrival. Maybe I should change the subject to say that more clearly.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de> To: Mike Snitzer <snitzer@redhat.com> Cc: Jens Axboe <axboe@fb.com>, linux-block@vger.kernel.org, dm-devel@redhat.com, Christoph Hellwig <hch@lst.de>, linux-scsi@vger.kernel.org Subject: Re: [PATCH 05/15] dm: remove incomple BLOCK_PC support Date: Fri, 13 Jan 2017 09:14:16 +0100 [thread overview] Message-ID: <20170113081416.GA26337@lst.de> (raw) In-Reply-To: <20170112222845.GA25349@redhat.com> On Thu, Jan 12, 2017 at 05:28:45PM -0500, Mike Snitzer wrote: > What is "incomplete" about request-based DM's BLOCK_PC support? BLOCK_PC requests are always aomething issued by the driver itself (for a broad defintion of the driver, aka everything under the block layer that works together is a driver for this purpose, e.g. all of the SCSI subsystem). If a driver doesn't issue BLOCK_PC requests itself or through library functions only called from the driver (e.g. scsi_cmd_ioctl) it is incomplete because it can't be used. > I'm also missing how you're saying the new blk-mq request-based DM will > work with your new model. I appreciate that we get the request from the > underlying blk-mq request_queue and it'll be properly sized. But > wouldn't we need to pass data back up for these SCSI pass-through > requests? So wouldn't the top-level multipath request_queue need to > setup cmd_size? As said above - supporting BLOCK_PC for dm does not make sense, as it's an internal passthrough mechanism for driver internal use. It just happened we standardized it at the block layer because SCSI commands are a standard supported by a few different drivers, e.g. SCSI itself, the old ide code for ATAPI and CCISS and virtio_blk which primarily are block drivers but allow some SCSI passthrough. To be honest I'd love to just fold BLOCK_PC into the SCSI layer sooner or later - the old IDE code and CCISS should die off sooner or later, and virtio_blk scsi passthrough was a horrible idea to start with (and I say that as the person who had the idea back then and implemented it..) > Sorry for the naive questions (that clearly speak to me not > understanding how this aspect of the block and SCSI code work).. but I'd > like to understand where DM will be lacking going forward. At least in terms of BLOCK_PC nothing will change for dm, the code was simply dead on arrival. Maybe I should change the subject to say that more clearly.
next prev parent reply other threads:[~2017-01-13 8:23 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-01-10 15:06 RFC: split scsi passthrough fields out of struct request Christoph Hellwig 2017-01-10 15:06 ` [PATCH 01/15] virtio_blk: avoid DMA to stack for the sense buffer Christoph Hellwig 2017-01-11 8:26 ` Johannes Thumshirn 2017-01-11 8:26 ` Johannes Thumshirn 2017-01-11 8:43 ` Christoph Hellwig 2017-01-10 15:06 ` [PATCH 02/15] nvme-rdma: fix nvme_rdma_queue_is_ready Christoph Hellwig 2017-01-10 15:06 ` [PATCH 03/15] block: simplify blk_init_allocated_queue Christoph Hellwig 2017-01-10 15:06 ` [PATCH 04/15] block: allow specifying size for extra command data Christoph Hellwig 2017-01-10 15:06 ` [PATCH 05/15] dm: remove incomple BLOCK_PC support Christoph Hellwig 2017-01-12 1:09 ` Mike Snitzer 2017-01-12 8:00 ` Christoph Hellwig 2017-01-12 22:28 ` Mike Snitzer 2017-01-13 8:14 ` Christoph Hellwig [this message] 2017-01-13 8:14 ` Christoph Hellwig 2017-01-10 15:06 ` [PATCH 06/15] scsi_dh_rdac: switch to scsi_execute_req_flags() Christoph Hellwig 2017-01-10 15:06 ` [PATCH 07/15] scsi_dh_emc: " Christoph Hellwig 2017-01-10 15:06 ` [PATCH 08/15] scsi_dh_hp_sw: " Christoph Hellwig 2017-01-10 15:06 ` [PATCH 09/15] scsi: remove gfp_flags member in scsi_host_cmd_pool Christoph Hellwig 2017-01-10 15:06 ` [PATCH 10/15] scsi: respect unchecked_isa_dma for blk-mq Christoph Hellwig 2017-01-10 15:06 ` [PATCH 11/15] scsi: remove scsi_cmd_dma_pool Christoph Hellwig 2017-01-10 15:06 ` [PATCH 12/15] scsi: remove __scsi_alloc_queue Christoph Hellwig 2017-01-10 15:06 ` [PATCH 13/15] scsi: allocate scsi_cmnd structures as part of struct request Christoph Hellwig 2017-01-10 15:06 ` [PATCH 14/15] block/bsg: move queue creation into bsg_setup_queue Christoph Hellwig 2017-01-11 8:42 ` Johannes Thumshirn 2017-01-11 8:42 ` Johannes Thumshirn 2017-01-11 8:45 ` Christoph Hellwig 2017-01-11 8:56 ` Johannes Thumshirn 2017-01-11 8:56 ` Johannes Thumshirn 2017-01-11 8:59 ` Christoph Hellwig 2017-01-11 8:59 ` Hannes Reinecke 2017-01-11 8:59 ` Hannes Reinecke 2017-01-11 9:01 ` Christoph Hellwig 2017-01-11 9:37 ` Hannes Reinecke 2017-01-11 9:37 ` Hannes Reinecke 2017-01-11 22:08 ` Mike Snitzer 2017-01-11 22:01 ` Mike Snitzer 2017-01-12 7:57 ` Christoph Hellwig 2017-01-10 15:06 ` [PATCH 15/15] block: split scsi_request out of struct request Christoph Hellwig 2017-01-12 3:59 ` Jens Axboe 2017-01-12 3:59 ` Jens Axboe 2017-01-11 22:41 ` RFC: split scsi passthrough fields " Mike Snitzer 2017-01-12 7:59 ` Christoph Hellwig
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170113081416.GA26337@lst.de \ --to=hch@lst.de \ --cc=axboe@fb.com \ --cc=dm-devel@redhat.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=snitzer@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.