Hello,
I would like to attend the 2013 Kernel Summit.
At the summit, I would like to discuss scsi-mq, a high performance SCSI
initiator prototype that utilizes the next-generation blk-mq effort by
Jens Axboe. The long-term goal is a path to move beyond the
long-standing small block random I/O limitations vs. raw make_request
based drivers of the existing Linux/SCSI client stack.
Along with using blk-mq's excellent native per-cpu primitive + NUMA
local friendly queuing of pre-allocated struct request descriptor
memory, the scsi-mq prototype currently avoids all I/O fast-path access
of legacy scsi_host->host_lock, and bypasses existing scsi_request_fn()
dispatch into scsi-mq enabled LLD code.
It also allows scsi-core to eliminate all fast-path memory allocations
using struct scsi_cmnd + $LLD_CMD pre-allocations based on a per struct
blk_mq_hw_ctx -> scsi_device->sdev_mq_req context, along with per
scsi_cmnd descriptor pre-allocation of SGL and sense buffer memory.
So far the initial conversion of virtio-scsi + scsi-debug LLDs has been
completed. Also, the intention is to keep the conversion requirements
for existing LLDs to scsi-mq as simple as possible.
There are still many areas that have been conveniently left out of the
initial prototype, including proper fast-path get_device() +
put_device() reference counting, a functioning scsi-generic IOCTL,
anything close to per struct scsi_device error handling, amongst other
things..
Drilling down the work items ahead of a real mainline push is high on
priority list for discussion.
The parties to be included in such a discussion are:
- Jens Axboe (blk-mq author)
- James Bottomley (scsi maintainer)
- Christoph Hellwig (scsi)
- Martin Petersen (scsi)
- Tejun Heo (block + libata)
- Hannes Reinecke (scsi error recovery)
- Kent Overstreet (block, per-cpu ida)
- Stephen Cameron (scsi-over-pcie driver)
- Andrew Vasquez (qla2xxx LLD)
- James Smart (lpfc LLD)
Thank you,
--nab
On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote:
> Drilling down the work items ahead of a real mainline push is high on
> priority list for discussion.
>
> The parties to be included in such a discussion are:
>
> - Jens Axboe (blk-mq author)
> - James Bottomley (scsi maintainer)
> - Christoph Hellwig (scsi)
> - Martin Petersen (scsi)
> - Tejun Heo (block + libata)
> - Hannes Reinecke (scsi error recovery)
> - Kent Overstreet (block, per-cpu ida)
> - Stephen Cameron (scsi-over-pcie driver)
> - Andrew Vasquez (qla2xxx LLD)
> - James Smart (lpfc LLD)
Isn't this something that should have been discussed at the storage
mini-summit a few months ago? It seems very specific to one subsystem
to be a kernel summit topic, don't you think?
thanks,
greg k-h
On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote:
> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote:
> > Drilling down the work items ahead of a real mainline push is high on
> > priority list for discussion.
> >
> > The parties to be included in such a discussion are:
> >
> > - Jens Axboe (blk-mq author)
> > - James Bottomley (scsi maintainer)
> > - Christoph Hellwig (scsi)
> > - Martin Petersen (scsi)
> > - Tejun Heo (block + libata)
> > - Hannes Reinecke (scsi error recovery)
> > - Kent Overstreet (block, per-cpu ida)
> > - Stephen Cameron (scsi-over-pcie driver)
> > - Andrew Vasquez (qla2xxx LLD)
> > - James Smart (lpfc LLD)
>
> Isn't this something that should have been discussed at the storage
> mini-summit a few months ago?
The scsi-mq prototype, along with blk-mq (in it's current form) did not
exist a few short months ago. ;)
> It seems very specific to one subsystem to be a kernel summit topic,
> don't you think?
It's no more subsystem specific than half of the other proposals so far,
and given it's reach across multiple subsystems (block, scsi, target),
and the amount of off-list interest on the topic, I think it would make
a good candidate for discussion.
Thanks,
--nab
On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote:
> On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote:
>> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote:
>>> Drilling down the work items ahead of a real mainline push is high on
>>> priority list for discussion.
>>>
>>> The parties to be included in such a discussion are:
>>>
>>> - Jens Axboe (blk-mq author)
>>> - James Bottomley (scsi maintainer)
>>> - Christoph Hellwig (scsi)
>>> - Martin Petersen (scsi)
>>> - Tejun Heo (block + libata)
>>> - Hannes Reinecke (scsi error recovery)
>>> - Kent Overstreet (block, per-cpu ida)
>>> - Stephen Cameron (scsi-over-pcie driver)
>>> - Andrew Vasquez (qla2xxx LLD)
>>> - James Smart (lpfc LLD)
>>
>> Isn't this something that should have been discussed at the storage
>> mini-summit a few months ago?
>
> The scsi-mq prototype, along with blk-mq (in it's current form) did not
> exist a few short months ago. ;)
>
>> It seems very specific to one subsystem to be a kernel summit topic,
>> don't you think?
>
> It's no more subsystem specific than half of the other proposals so far,
> and given it's reach across multiple subsystems (block, scsi, target),
> and the amount of off-list interest on the topic, I think it would make
> a good candidate for discussion.
>
And it'll open up new approaches which previously were dismissed,
like re-implementing multipathing on top of scsi-mq, giving us the
single scsi device like other UNIX systems.
Also I do think there's quite some synergy to be had, as with blk-mq
we could nail each queue to a processor, which would eliminate the
need for locking.
Which could be useful for other subsystems, too.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
[email protected] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote:
> On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote:
> > On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote:
> >> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote:
> >>> Drilling down the work items ahead of a real mainline push is high on
> >>> priority list for discussion.
> >>>
> >>> The parties to be included in such a discussion are:
> >>>
> >>> - Jens Axboe (blk-mq author)
> >>> - James Bottomley (scsi maintainer)
> >>> - Christoph Hellwig (scsi)
> >>> - Martin Petersen (scsi)
> >>> - Tejun Heo (block + libata)
> >>> - Hannes Reinecke (scsi error recovery)
> >>> - Kent Overstreet (block, per-cpu ida)
> >>> - Stephen Cameron (scsi-over-pcie driver)
> >>> - Andrew Vasquez (qla2xxx LLD)
> >>> - James Smart (lpfc LLD)
> >>
> >> Isn't this something that should have been discussed at the storage
> >> mini-summit a few months ago?
> >
> > The scsi-mq prototype, along with blk-mq (in it's current form) did not
> > exist a few short months ago. ;)
> >
> >> It seems very specific to one subsystem to be a kernel summit topic,
> >> don't you think?
> >
> > It's no more subsystem specific than half of the other proposals so far,
> > and given it's reach across multiple subsystems (block, scsi, target),
> > and the amount of off-list interest on the topic, I think it would make
> > a good candidate for discussion.
> >
> And it'll open up new approaches which previously were dismissed,
> like re-implementing multipathing on top of scsi-mq, giving us the
> single scsi device like other UNIX systems.
>
> Also I do think there's quite some synergy to be had, as with blk-mq
> we could nail each queue to a processor, which would eliminate the
> need for locking.
> Which could be useful for other subsystems, too.
Lets start with discussing this on the list, please, and then see where
we go from there ...
James
On Sat, 2013-07-13 at 06:53 +0000, James Bottomley wrote:
> On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote:
> > On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote:
> > > On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote:
> > >> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote:
> > >>> Drilling down the work items ahead of a real mainline push is high on
> > >>> priority list for discussion.
> > >>>
> > >>> The parties to be included in such a discussion are:
> > >>>
> > >>> - Jens Axboe (blk-mq author)
> > >>> - James Bottomley (scsi maintainer)
> > >>> - Christoph Hellwig (scsi)
> > >>> - Martin Petersen (scsi)
> > >>> - Tejun Heo (block + libata)
> > >>> - Hannes Reinecke (scsi error recovery)
> > >>> - Kent Overstreet (block, per-cpu ida)
> > >>> - Stephen Cameron (scsi-over-pcie driver)
> > >>> - Andrew Vasquez (qla2xxx LLD)
> > >>> - James Smart (lpfc LLD)
> > >>
> > >> Isn't this something that should have been discussed at the storage
> > >> mini-summit a few months ago?
> > >
> > > The scsi-mq prototype, along with blk-mq (in it's current form) did not
> > > exist a few short months ago. ;)
> > >
> > >> It seems very specific to one subsystem to be a kernel summit topic,
> > >> don't you think?
> > >
> > > It's no more subsystem specific than half of the other proposals so far,
> > > and given it's reach across multiple subsystems (block, scsi, target),
> > > and the amount of off-list interest on the topic, I think it would make
> > > a good candidate for discussion.
> > >
> > And it'll open up new approaches which previously were dismissed,
> > like re-implementing multipathing on top of scsi-mq, giving us the
> > single scsi device like other UNIX systems.
> >
> > Also I do think there's quite some synergy to be had, as with blk-mq
> > we could nail each queue to a processor, which would eliminate the
> > need for locking.
> > Which could be useful for other subsystems, too.
>
> Lets start with discussing this on the list, please, and then see where
> we go from there ...
>
Yes, the discussion is beginning to make it's way to the list. I've
mostly been waiting for blk-mq to get a wider review before taking the
early scsi-mq prototype driver to a larger public audience.
Primarily, I'm now reaching out to the people most effected by existing
scsi_request_fn() based performance limitations. Most of them have
abandoned existing scsi_request_fn() based logic in favor of raw block
make_request() based drivers, and are now estimating the amount of
effort to move to an scsi-mq based approach.
Regardless, as the prototype progresses over the next months, having a
face-to-face discussion with the key parties in the room would be very
helpful given the large amount of effort involved to actually make this
type of generational shift in SCSI actually happen.
--nab
On Tue, Jul 16 2013, Nicholas A. Bellinger wrote:
> On Sat, 2013-07-13 at 06:53 +0000, James Bottomley wrote:
> > On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote:
> > > On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote:
> > > > On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote:
> > > >> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote:
> > > >>> Drilling down the work items ahead of a real mainline push is high on
> > > >>> priority list for discussion.
> > > >>>
> > > >>> The parties to be included in such a discussion are:
> > > >>>
> > > >>> - Jens Axboe (blk-mq author)
> > > >>> - James Bottomley (scsi maintainer)
> > > >>> - Christoph Hellwig (scsi)
> > > >>> - Martin Petersen (scsi)
> > > >>> - Tejun Heo (block + libata)
> > > >>> - Hannes Reinecke (scsi error recovery)
> > > >>> - Kent Overstreet (block, per-cpu ida)
> > > >>> - Stephen Cameron (scsi-over-pcie driver)
> > > >>> - Andrew Vasquez (qla2xxx LLD)
> > > >>> - James Smart (lpfc LLD)
> > > >>
> > > >> Isn't this something that should have been discussed at the storage
> > > >> mini-summit a few months ago?
> > > >
> > > > The scsi-mq prototype, along with blk-mq (in it's current form) did not
> > > > exist a few short months ago. ;)
> > > >
> > > >> It seems very specific to one subsystem to be a kernel summit topic,
> > > >> don't you think?
> > > >
> > > > It's no more subsystem specific than half of the other proposals so far,
> > > > and given it's reach across multiple subsystems (block, scsi, target),
> > > > and the amount of off-list interest on the topic, I think it would make
> > > > a good candidate for discussion.
> > > >
> > > And it'll open up new approaches which previously were dismissed,
> > > like re-implementing multipathing on top of scsi-mq, giving us the
> > > single scsi device like other UNIX systems.
> > >
> > > Also I do think there's quite some synergy to be had, as with blk-mq
> > > we could nail each queue to a processor, which would eliminate the
> > > need for locking.
> > > Which could be useful for other subsystems, too.
> >
> > Lets start with discussing this on the list, please, and then see where
> > we go from there ...
> >
>
> Yes, the discussion is beginning to make it's way to the list. I've
> mostly been waiting for blk-mq to get a wider review before taking the
> early scsi-mq prototype driver to a larger public audience.
>
> Primarily, I'm now reaching out to the people most effected by existing
> scsi_request_fn() based performance limitations. Most of them have
> abandoned existing scsi_request_fn() based logic in favor of raw block
> make_request() based drivers, and are now estimating the amount of
> effort to move to an scsi-mq based approach.
>
> Regardless, as the prototype progresses over the next months, having a
> face-to-face discussion with the key parties in the room would be very
> helpful given the large amount of effort involved to actually make this
> type of generational shift in SCSI actually happen.
There's a certain amount of overlap with the aio/O_DIRECT work as well.
But if it's not a general session, could always be a BOF or something.
I'll second the argument that most technical topics probably DO belong
in a topic related workshop. But that leaves us with basically only
process related topics at KS, I don't think it hurts to have a bit of
tech meat on the bone too. At least I personally miss that part of KS
from years gone by.
--
Jens Axboe
On Tue, Jul 16, 2013 at 02:07:29PM -0700, Nicholas A. Bellinger wrote:
> On Sat, 2013-07-13 at 06:53 +0000, James Bottomley wrote:
> > On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote:
> > > On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote:
> > > > On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote:
> > > >> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote:
> > > >>> Drilling down the work items ahead of a real mainline push is high on
> > > >>> priority list for discussion.
> > > >>>
> > > >>> The parties to be included in such a discussion are:
> > > >>>
> > > >>> - Jens Axboe (blk-mq author)
> > > >>> - James Bottomley (scsi maintainer)
> > > >>> - Christoph Hellwig (scsi)
> > > >>> - Martin Petersen (scsi)
> > > >>> - Tejun Heo (block + libata)
> > > >>> - Hannes Reinecke (scsi error recovery)
> > > >>> - Kent Overstreet (block, per-cpu ida)
> > > >>> - Stephen Cameron (scsi-over-pcie driver)
> > > >>> - Andrew Vasquez (qla2xxx LLD)
> > > >>> - James Smart (lpfc LLD)
> > > >>
> > > >> Isn't this something that should have been discussed at the storage
> > > >> mini-summit a few months ago?
> > > >
> > > > The scsi-mq prototype, along with blk-mq (in it's current form) did not
> > > > exist a few short months ago. ;)
> > > >
> > > >> It seems very specific to one subsystem to be a kernel summit topic,
> > > >> don't you think?
> > > >
> > > > It's no more subsystem specific than half of the other proposals so far,
> > > > and given it's reach across multiple subsystems (block, scsi, target),
> > > > and the amount of off-list interest on the topic, I think it would make
> > > > a good candidate for discussion.
> > > >
> > > And it'll open up new approaches which previously were dismissed,
> > > like re-implementing multipathing on top of scsi-mq, giving us the
> > > single scsi device like other UNIX systems.
> > >
> > > Also I do think there's quite some synergy to be had, as with blk-mq
> > > we could nail each queue to a processor, which would eliminate the
> > > need for locking.
> > > Which could be useful for other subsystems, too.
> >
> > Lets start with discussing this on the list, please, and then see where
> > we go from there ...
> >
>
> Yes, the discussion is beginning to make it's way to the list. I've
> mostly been waiting for blk-mq to get a wider review before taking the
> early scsi-mq prototype driver to a larger public audience.
>
> Primarily, I'm now reaching out to the people most effected by existing
> scsi_request_fn() based performance limitations. Most of them have
> abandoned existing scsi_request_fn() based logic in favor of raw block
> make_request() based drivers, and are now estimating the amount of
> effort to move to an scsi-mq based approach.
>
> Regardless, as the prototype progresses over the next months, having a
> face-to-face discussion with the key parties in the room would be very
> helpful given the large amount of effort involved to actually make this
> type of generational shift in SCSI actually happen.
I'd be very interested in attending this, if invited.
-- steve
On Tue, 2013-07-16 at 15:15 -0600, Jens Axboe wrote:
> On Tue, Jul 16 2013, Nicholas A. Bellinger wrote:
> > On Sat, 2013-07-13 at 06:53 +0000, James Bottomley wrote:
> > > On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote:
> > > > On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote:
> > > > > On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote:
> > > > >> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote:
> > > > >>> Drilling down the work items ahead of a real mainline push is high on
> > > > >>> priority list for discussion.
> > > > >>>
> > > > >>> The parties to be included in such a discussion are:
> > > > >>>
> > > > >>> - Jens Axboe (blk-mq author)
> > > > >>> - James Bottomley (scsi maintainer)
> > > > >>> - Christoph Hellwig (scsi)
> > > > >>> - Martin Petersen (scsi)
> > > > >>> - Tejun Heo (block + libata)
> > > > >>> - Hannes Reinecke (scsi error recovery)
> > > > >>> - Kent Overstreet (block, per-cpu ida)
> > > > >>> - Stephen Cameron (scsi-over-pcie driver)
> > > > >>> - Andrew Vasquez (qla2xxx LLD)
> > > > >>> - James Smart (lpfc LLD)
> > > > >>
> > > > >> Isn't this something that should have been discussed at the storage
> > > > >> mini-summit a few months ago?
> > > > >
> > > > > The scsi-mq prototype, along with blk-mq (in it's current form) did not
> > > > > exist a few short months ago. ;)
> > > > >
> > > > >> It seems very specific to one subsystem to be a kernel summit topic,
> > > > >> don't you think?
> > > > >
> > > > > It's no more subsystem specific than half of the other proposals so far,
> > > > > and given it's reach across multiple subsystems (block, scsi, target),
> > > > > and the amount of off-list interest on the topic, I think it would make
> > > > > a good candidate for discussion.
> > > > >
> > > > And it'll open up new approaches which previously were dismissed,
> > > > like re-implementing multipathing on top of scsi-mq, giving us the
> > > > single scsi device like other UNIX systems.
> > > >
> > > > Also I do think there's quite some synergy to be had, as with blk-mq
> > > > we could nail each queue to a processor, which would eliminate the
> > > > need for locking.
> > > > Which could be useful for other subsystems, too.
> > >
> > > Lets start with discussing this on the list, please, and then see where
> > > we go from there ...
> > >
> >
> > Yes, the discussion is beginning to make it's way to the list. I've
> > mostly been waiting for blk-mq to get a wider review before taking the
> > early scsi-mq prototype driver to a larger public audience.
> >
> > Primarily, I'm now reaching out to the people most effected by existing
> > scsi_request_fn() based performance limitations. Most of them have
> > abandoned existing scsi_request_fn() based logic in favor of raw block
> > make_request() based drivers, and are now estimating the amount of
> > effort to move to an scsi-mq based approach.
> >
> > Regardless, as the prototype progresses over the next months, having a
> > face-to-face discussion with the key parties in the room would be very
> > helpful given the large amount of effort involved to actually make this
> > type of generational shift in SCSI actually happen.
>
> There's a certain amount of overlap with the aio/O_DIRECT work as well.
> But if it's not a general session, could always be a BOF or something.
>
> I'll second the argument that most technical topics probably DO belong
> in a topic related workshop. But that leaves us with basically only
> process related topics at KS, I don't think it hurts to have a bit of
> tech meat on the bone too. At least I personally miss that part of KS
> from years gone by.
Heh well, given that most of the block mq discussions at LSF have been
you saying you really should get around to cleaning up and posting the
code, you'll understand my wanting to see that happen first ...
I suppose we could try to run a storage workshop within KS, but I think
most of the mini summit slots have already gone. There's also plumbers
if all slots are gone (I would say that, being biased and on the
programme committee) Ric is running the storage and Filesystems MC
http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/tracks/159
James
On 07/17/2013 12:52 AM, James Bottomley wrote:
> On Tue, 2013-07-16 at 15:15 -0600, Jens Axboe wrote:
>> On Tue, Jul 16 2013, Nicholas A. Bellinger wrote:
>>> On Sat, 2013-07-13 at 06:53 +0000, James Bottomley wrote:
>>>> On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote:
>>>>> On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote:
>>>>>> On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote:
>>>>>>> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote:
>>>>>>>> Drilling down the work items ahead of a real mainline push is high on
>>>>>>>> priority list for discussion.
>>>>>>>>
>>>>>>>> The parties to be included in such a discussion are:
>>>>>>>>
>>>>>>>> - Jens Axboe (blk-mq author)
>>>>>>>> - James Bottomley (scsi maintainer)
>>>>>>>> - Christoph Hellwig (scsi)
>>>>>>>> - Martin Petersen (scsi)
>>>>>>>> - Tejun Heo (block + libata)
>>>>>>>> - Hannes Reinecke (scsi error recovery)
>>>>>>>> - Kent Overstreet (block, per-cpu ida)
>>>>>>>> - Stephen Cameron (scsi-over-pcie driver)
>>>>>>>> - Andrew Vasquez (qla2xxx LLD)
>>>>>>>> - James Smart (lpfc LLD)
>>>>>>> Isn't this something that should have been discussed at the storage
>>>>>>> mini-summit a few months ago?
>>>>>> The scsi-mq prototype, along with blk-mq (in it's current form) did not
>>>>>> exist a few short months ago. ;)
>>>>>>
>>>>>>> It seems very specific to one subsystem to be a kernel summit topic,
>>>>>>> don't you think?
>>>>>> It's no more subsystem specific than half of the other proposals so far,
>>>>>> and given it's reach across multiple subsystems (block, scsi, target),
>>>>>> and the amount of off-list interest on the topic, I think it would make
>>>>>> a good candidate for discussion.
>>>>>>
>>>>> And it'll open up new approaches which previously were dismissed,
>>>>> like re-implementing multipathing on top of scsi-mq, giving us the
>>>>> single scsi device like other UNIX systems.
>>>>>
>>>>> Also I do think there's quite some synergy to be had, as with blk-mq
>>>>> we could nail each queue to a processor, which would eliminate the
>>>>> need for locking.
>>>>> Which could be useful for other subsystems, too.
>>>> Lets start with discussing this on the list, please, and then see where
>>>> we go from there ...
>>>>
>>> Yes, the discussion is beginning to make it's way to the list. I've
>>> mostly been waiting for blk-mq to get a wider review before taking the
>>> early scsi-mq prototype driver to a larger public audience.
>>>
>>> Primarily, I'm now reaching out to the people most effected by existing
>>> scsi_request_fn() based performance limitations. Most of them have
>>> abandoned existing scsi_request_fn() based logic in favor of raw block
>>> make_request() based drivers, and are now estimating the amount of
>>> effort to move to an scsi-mq based approach.
>>>
>>> Regardless, as the prototype progresses over the next months, having a
>>> face-to-face discussion with the key parties in the room would be very
>>> helpful given the large amount of effort involved to actually make this
>>> type of generational shift in SCSI actually happen.
>> There's a certain amount of overlap with the aio/O_DIRECT work as well.
>> But if it's not a general session, could always be a BOF or something.
>>
>> I'll second the argument that most technical topics probably DO belong
>> in a topic related workshop. But that leaves us with basically only
>> process related topics at KS, I don't think it hurts to have a bit of
>> tech meat on the bone too. At least I personally miss that part of KS
>> from years gone by.
> Heh well, given that most of the block mq discussions at LSF have been
> you saying you really should get around to cleaning up and posting the
> code, you'll understand my wanting to see that happen first ...
>
> I suppose we could try to run a storage workshop within KS, but I think
> most of the mini summit slots have already gone. There's also plumbers
> if all slots are gone (I would say that, being biased and on the
> programme committee) Ric is running the storage and Filesystems MC
>
> http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/tracks/159
>
> James
>
And we still are looking for suggested topics - it would be great to have the
multi-queue work at plumbers.
You can post a proposal for it (or other topics) here:
http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/proposals
Ric
On Wed, 2013-07-17 at 04:52 +0000, James Bottomley wrote:
> On Tue, 2013-07-16 at 15:15 -0600, Jens Axboe wrote:
> > On Tue, Jul 16 2013, Nicholas A. Bellinger wrote:
> > > On Sat, 2013-07-13 at 06:53 +0000, James Bottomley wrote:
<SNIP>
> > > > Lets start with discussing this on the list, please, and then see where
> > > > we go from there ...
> > > >
> > >
> > > Yes, the discussion is beginning to make it's way to the list. I've
> > > mostly been waiting for blk-mq to get a wider review before taking the
> > > early scsi-mq prototype driver to a larger public audience.
> > >
> > > Primarily, I'm now reaching out to the people most effected by existing
> > > scsi_request_fn() based performance limitations. Most of them have
> > > abandoned existing scsi_request_fn() based logic in favor of raw block
> > > make_request() based drivers, and are now estimating the amount of
> > > effort to move to an scsi-mq based approach.
> > >
> > > Regardless, as the prototype progresses over the next months, having a
> > > face-to-face discussion with the key parties in the room would be very
> > > helpful given the large amount of effort involved to actually make this
> > > type of generational shift in SCSI actually happen.
> >
> > There's a certain amount of overlap with the aio/O_DIRECT work as well.
> > But if it's not a general session, could always be a BOF or something.
> >
> > I'll second the argument that most technical topics probably DO belong
> > in a topic related workshop. But that leaves us with basically only
> > process related topics at KS, I don't think it hurts to have a bit of
> > tech meat on the bone too. At least I personally miss that part of KS
> > from years gone by.
>
> Heh well, given that most of the block mq discussions at LSF have been
> you saying you really should get around to cleaning up and posting the
> code, you'll understand my wanting to see that happen first ...
>
> I suppose we could try to run a storage workshop within KS, but I think
> most of the mini summit slots have already gone.
That would be great, given there is a reasonable level of interest from
various parities, and the pain threshold for existing scsi small block
random I/O performance is high..
When will we know if there is a workshop / mini summit slot available..?
(CC'ing Mike Christie as well for open-iscsi/scsi-mq bits)
> There's also plumbers
> if all slots are gone (I would say that, being biased and on the
> programme committee) Ric is running the storage and Filesystems MC
>
> http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/tracks/159
FYI, I'm not trying to 'sell' scsi-mq to the larger community yet, but
rather interested in getting the right scsi/block/LLD people in the same
room at KS for an hour or two to discuss implementation details, given
the scope of the effort involved.
--nab
On Fri, 2013-07-19 at 14:22 -0700, Nicholas A. Bellinger wrote:
> On Wed, 2013-07-17 at 04:52 +0000, James Bottomley wrote:
> > On Tue, 2013-07-16 at 15:15 -0600, Jens Axboe wrote:
> > > On Tue, Jul 16 2013, Nicholas A. Bellinger wrote:
> > > > On Sat, 2013-07-13 at 06:53 +0000, James Bottomley wrote:
>
> <SNIP>
>
> > > > > Lets start with discussing this on the list, please, and then see where
> > > > > we go from there ...
> > > > >
> > > >
> > > > Yes, the discussion is beginning to make it's way to the list. I've
> > > > mostly been waiting for blk-mq to get a wider review before taking the
> > > > early scsi-mq prototype driver to a larger public audience.
> > > >
> > > > Primarily, I'm now reaching out to the people most effected by existing
> > > > scsi_request_fn() based performance limitations. Most of them have
> > > > abandoned existing scsi_request_fn() based logic in favor of raw block
> > > > make_request() based drivers, and are now estimating the amount of
> > > > effort to move to an scsi-mq based approach.
> > > >
> > > > Regardless, as the prototype progresses over the next months, having a
> > > > face-to-face discussion with the key parties in the room would be very
> > > > helpful given the large amount of effort involved to actually make this
> > > > type of generational shift in SCSI actually happen.
> > >
> > > There's a certain amount of overlap with the aio/O_DIRECT work as well.
> > > But if it's not a general session, could always be a BOF or something.
> > >
> > > I'll second the argument that most technical topics probably DO belong
> > > in a topic related workshop. But that leaves us with basically only
> > > process related topics at KS, I don't think it hurts to have a bit of
> > > tech meat on the bone too. At least I personally miss that part of KS
> > > from years gone by.
> >
> > Heh well, given that most of the block mq discussions at LSF have been
> > you saying you really should get around to cleaning up and posting the
> > code, you'll understand my wanting to see that happen first ...
> >
> > I suppose we could try to run a storage workshop within KS, but I think
> > most of the mini summit slots have already gone.
>
> That would be great, given there is a reasonable level of interest from
> various parities, and the pain threshold for existing scsi small block
> random I/O performance is high..
>
> When will we know if there is a workshop / mini summit slot available..?
>
> (CC'ing Mike Christie as well for open-iscsi/scsi-mq bits)
>
> > There's also plumbers
> > if all slots are gone (I would say that, being biased and on the
> > programme committee) Ric is running the storage and Filesystems MC
> >
> > http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/tracks/159
>
> FYI, I'm not trying to 'sell' scsi-mq to the larger community yet, but
> rather interested in getting the right scsi/block/LLD people in the same
> room at KS for an hour or two to discuss implementation details, given
> the scope of the effort involved.
Well, so that's why I think plumbers might be a better venue: we'll have
more of the actual storage people there. Usually we get at most 2-3
storage people to KS compared to the 25 or so we usually have at LSF ...
that makes KS not a very good venue for storage centric discussions.
James
On Fri, 2013-07-19 at 21:46 +0000, James Bottomley wrote:
> On Fri, 2013-07-19 at 14:22 -0700, Nicholas A. Bellinger wrote:
> > On Wed, 2013-07-17 at 04:52 +0000, James Bottomley wrote:
> > > On Tue, 2013-07-16 at 15:15 -0600, Jens Axboe wrote:
> > > > On Tue, Jul 16 2013, Nicholas A. Bellinger wrote:
> > > > > On Sat, 2013-07-13 at 06:53 +0000, James Bottomley wrote:
> >
> > <SNIP>
> >
> > > > > > Lets start with discussing this on the list, please, and then see where
> > > > > > we go from there ...
> > > > > >
> > > > >
> > > > > Yes, the discussion is beginning to make it's way to the list. I've
> > > > > mostly been waiting for blk-mq to get a wider review before taking the
> > > > > early scsi-mq prototype driver to a larger public audience.
> > > > >
> > > > > Primarily, I'm now reaching out to the people most effected by existing
> > > > > scsi_request_fn() based performance limitations. Most of them have
> > > > > abandoned existing scsi_request_fn() based logic in favor of raw block
> > > > > make_request() based drivers, and are now estimating the amount of
> > > > > effort to move to an scsi-mq based approach.
> > > > >
> > > > > Regardless, as the prototype progresses over the next months, having a
> > > > > face-to-face discussion with the key parties in the room would be very
> > > > > helpful given the large amount of effort involved to actually make this
> > > > > type of generational shift in SCSI actually happen.
> > > >
> > > > There's a certain amount of overlap with the aio/O_DIRECT work as well.
> > > > But if it's not a general session, could always be a BOF or something.
> > > >
> > > > I'll second the argument that most technical topics probably DO belong
> > > > in a topic related workshop. But that leaves us with basically only
> > > > process related topics at KS, I don't think it hurts to have a bit of
> > > > tech meat on the bone too. At least I personally miss that part of KS
> > > > from years gone by.
> > >
> > > Heh well, given that most of the block mq discussions at LSF have been
> > > you saying you really should get around to cleaning up and posting the
> > > code, you'll understand my wanting to see that happen first ...
> > >
> > > I suppose we could try to run a storage workshop within KS, but I think
> > > most of the mini summit slots have already gone.
> >
> > That would be great, given there is a reasonable level of interest from
> > various parities, and the pain threshold for existing scsi small block
> > random I/O performance is high..
> >
> > When will we know if there is a workshop / mini summit slot available..?
> >
> > (CC'ing Mike Christie as well for open-iscsi/scsi-mq bits)
> >
> > > There's also plumbers
> > > if all slots are gone (I would say that, being biased and on the
> > > programme committee) Ric is running the storage and Filesystems MC
> > >
> > > http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/tracks/159
> >
> > FYI, I'm not trying to 'sell' scsi-mq to the larger community yet, but
> > rather interested in getting the right scsi/block/LLD people in the same
> > room at KS for an hour or two to discuss implementation details, given
> > the scope of the effort involved.
>
> Well, so that's why I think plumbers might be a better venue: we'll have
> more of the actual storage people there. Usually we get at most 2-3
> storage people to KS compared to the 25 or so we usually have at LSF ...
> that makes KS not a very good venue for storage centric discussions.
>
The most relevant people for the discussion are Jens, Hannes, Christoph,
Tejun, Martin, Mike, and you.
I know these folks are regular attendees for KS, but typically not for
plumbers, which is why I made this KS topic proposal in the first place.
--nab
On Fri, Jul 19 2013, Ric Wheeler wrote:
> down the work items ahead of a real mainline push is high on
> >>>>>>>>priority list for discussion.
> >>>>>>>>
> >>>>>>>>The parties to be included in such a discussion are:
> >>>>>>>>
> >>>>>>>> - Jens Axboe (blk-mq author)
> >>>>>>>> - James Bottomley (scsi maintainer)
> >>>>>>>> - Christoph Hellwig (scsi)
> >>>>>>>> - Martin Petersen (scsi)
> >>>>>>>> - Tejun Heo (block + libata)
> >>>>>>>> - Hannes Reinecke (scsi error recovery)
> >>>>>>>> - Kent Overstreet (block, per-cpu ida)
> >>>>>>>> - Stephen Cameron (scsi-over-pcie driver)
> >>>>>>>> - Andrew Vasquez (qla2xxx LLD)
> >>>>>>>> - James Smart (lpfc LLD)
> >>>>>>>Isn't this something that should have been discussed at the storage
> >>>>>>>mini-summit a few months ago?
> >>>>>>The scsi-mq prototype, along with blk-mq (in it's current form) did not
> >>>>>>exist a few short months ago. ;)
> >>>>>>
> >>>>>>> It seems very specific to one subsystem to be a kernel summit topic,
> >>>>>>>don't you think?
> >>>>>>It's no more subsystem specific than half of the other proposals so far,
> >>>>>>and given it's reach across multiple subsystems (block, scsi, target),
> >>>>>>and the amount of off-list interest on the topic, I think it would make
> >>>>>>a good candidate for discussion.
> >>>>>>
> >>>>>And it'll open up new approaches which previously were dismissed,
> >>>>>like re-implementing multipathing on top of scsi-mq, giving us the
> >>>>>single scsi device like other UNIX systems.
> >>>>>
> >>>>>Also I do think there's quite some synergy to be had, as with blk-mq
> >>>>>we could nail each queue to a processor, which would eliminate the
> >>>>>need for locking.
> >>>>>Which could be useful for other subsystems, too.
> >>>>Lets start with discussing this on the list, please, and then see where
> >>>>we go from there ...
> >>>>
> >>>Yes, the discussion is beginning to make it's way to the list. I've
> >>>mostly been waiting for blk-mq to get a wider review before taking the
> >>>early scsi-mq prototype driver to a larger public audience.
> >>>
> >>>Primarily, I'm now reaching out to the people most effected by existing
> >>>scsi_request_fn() based performance limitations. Most of them have
> >>>abandoned existing scsi_request_fn() based logic in favor of raw block
> >>>make_request() based drivers, and are now estimating the amount of
> >>>effort to move to an scsi-mq based approach.
> >>>
> >>>Regardless, as the prototype progresses over the next months, having a
> >>>face-to-face discussion with the key parties in the room would be very
> >>>helpful given the large amount of effort involved to actually make this
> >>>type of generational shift in SCSI actually happen.
> >>There's a certain amount of overlap with the aio/O_DIRECT work as well.
> >>But if it's not a general session, could always be a BOF or something.
> >>
> >>I'll second the argument that most technical topics probably DO belong
> >>in a topic related workshop. But that leaves us with basically only
> >>process related topics at KS, I don't think it hurts to have a bit of
> >>tech meat on the bone too. At least I personally miss that part of KS
> >>from years gone by.
> >Heh well, given that most of the block mq discussions at LSF have been
> >you saying you really should get around to cleaning up and posting the
> >code, you'll understand my wanting to see that happen first ...
> >
> >I suppose we could try to run a storage workshop within KS, but I think
> >most of the mini summit slots have already gone. There's also plumbers
> >if all slots are gone (I would say that, being biased and on the
> >programme committee) Ric is running the storage and Filesystems MC
> >
> >http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/tracks/159
> >
> >James
> >
>
> And we still are looking for suggested topics - it would be great to have
> the multi-queue work at plumbers.
>
> You can post a proposal for it (or other topics) here:
>
> http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/proposals
FWIW, I can't make Plumbers this year, unfortunately.
--
Jens Axboe