[LSF/MM TOPIC] LIO/SCST Merger

[LSF/MM TOPIC] LIO/SCST Merger

[Bart Van Assche]

Last year, during the 2015 LSF/MM summit, it has been decided that the 
LIO/SCST merger project should proceed by sending the functionality 
upstream that is present in SCST but not yet in LIO. This will help to 
reduce the workload of target driver maintainers that maintain a version 
of their target driver for both LIO and SCST (QLogic FC and FCoE target 
drivers, Emulex FC and FCoE target drivers, RDMA iSER target driver, 
RDMA SRP target driver, ...). My proposal is to organize a session 
during which the following is discussed:
* Which patches are already upstream in the context of the LIO/SCST 
merger project.
* About which patches there is agreement but that are not yet upstream.
* To discuss how to proceed from here and what to address first.

References:
[1] Bart Van Assche,  [LSF/MM TOPIC] Unifying the LIO and SCST target 
drivers, January 2015 
(http://thread.gmane.org/gmane.linux.scsi.target.devel/7779)
[2] James Bottomley, LIO/SCST merger, April 2015 
(https://plus.google.com/112086662098298535411/posts/HuGsCMU41uy).

Re: [Lsf-pc] [LSF/MM TOPIC] LIO/SCST Merger

[James Bottomley]

On Wed, 2016-01-27 at 09:54 -0800, Bart Van Assche wrote:
> Last year, during the 2015 LSF/MM summit, it has been decided that 
> the LIO/SCST merger project should proceed by sending the 
> functionality upstream that is present in SCST but not yet in LIO. 
> This will help to reduce the workload of target driver maintainers 
> that maintain a version of their target driver for both LIO and SCST 
> (QLogic FC and FCoE target drivers, Emulex FC and FCoE target 
> drivers, RDMA iSER target driver, RDMA SRP target driver, ...). My 
> proposal is to organize a session during which the following is
> discussed:
> * Which patches are already upstream in the context of the LIO/SCST 
> merger project.
> * About which patches there is agreement but that are not yet
> upstream.
> * To discuss how to proceed from here and what to address first.

Can you begin this in email ... I don't think any of us are clear if
there's still an issue here ... or that we'd say more than send the
patches upstream, like we did last year.  Just reporting on patch
status isn't that useful ... if there were design disputes or issues to
discuss that caused the patches not to be accepted, that would be more
useful.

James

Re: [Lsf-pc] [LSF/MM TOPIC] LIO/SCST Merger

[Bart Van Assche]

On 01/27/2016 10:08 AM, James Bottomley wrote:
> On Wed, 2016-01-27 at 09:54 -0800, Bart Van Assche wrote:
>> Last year, during the 2015 LSF/MM summit, it has been decided that
>> the LIO/SCST merger project should proceed by sending the
>> functionality upstream that is present in SCST but not yet in LIO.
>> This will help to reduce the workload of target driver maintainers
>> that maintain a version of their target driver for both LIO and SCST
>> (QLogic FC and FCoE target drivers, Emulex FC and FCoE target
>> drivers, RDMA iSER target driver, RDMA SRP target driver, ...). My
>> proposal is to organize a session during which the following is
>> discussed:
>> * Which patches are already upstream in the context of the LIO/SCST
>> merger project.
>> * About which patches there is agreement but that are not yet
>> upstream.
>> * To discuss how to proceed from here and what to address first.
>
> Can you begin this in email ... I don't think any of us are clear if
> there's still an issue here ... or that we'd say more than send the
> patches upstream, like we did last year.  Just reporting on patch
> status isn't that useful ... if there were design disputes or issues to
> discuss that caused the patches not to be accepted, that would be more
> useful.

Hello James,

Several patch series have been posted by different authors. Some of 
these patch series have already been reworked several times for 
different kernel versions. I think a meeting in person would make it 
easier to discuss which patch series to take upstream first and thereby 
avoid to have to keep reworking these patch series against an evolving 
target API. These patch series are:

* Christoph Hellwig, [RFC] simplify session shutdown, January 14 
(http://thread.gmane.org/gmane.linux.scsi.target.devel/11135).
* Nicholas Bellinger, [PATCH 0/2] target: Fix LUN_RESET active I/O + TMR 
handling, January 12, 2016 
(http://thread.gmane.org/gmane.linux.scsi.target.devel/11097).
* Bart Van Assche,  [PATCH 00/21] SCSI target patches for kernel v4.5, 
January 5 (http://thread.gmane.org/gmane.linux.scsi.target.devel/10905).

Thanks,

Bart.

Re: [Lsf-pc] [LSF/MM TOPIC] LIO/SCST Merger

[James Bottomley]

On Wed, 2016-01-27 at 10:19 -0800, Bart Van Assche wrote:
> On 01/27/2016 10:08 AM, James Bottomley wrote:
> > On Wed, 2016-01-27 at 09:54 -0800, Bart Van Assche wrote:
> > > Last year, during the 2015 LSF/MM summit, it has been decided
> > > that
> > > the LIO/SCST merger project should proceed by sending the
> > > functionality upstream that is present in SCST but not yet in
> > > LIO.
> > > This will help to reduce the workload of target driver
> > > maintainers
> > > that maintain a version of their target driver for both LIO and
> > > SCST
> > > (QLogic FC and FCoE target drivers, Emulex FC and FCoE target
> > > drivers, RDMA iSER target driver, RDMA SRP target driver, ...).
> > > My
> > > proposal is to organize a session during which the following is
> > > discussed:
> > > * Which patches are already upstream in the context of the
> > > LIO/SCST
> > > merger project.
> > > * About which patches there is agreement but that are not yet
> > > upstream.
> > > * To discuss how to proceed from here and what to address first.
> > 
> > Can you begin this in email ... I don't think any of us are clear
> > if
> > there's still an issue here ... or that we'd say more than send the
> > patches upstream, like we did last year.  Just reporting on patch
> > status isn't that useful ... if there were design disputes or
> > issues to
> > discuss that caused the patches not to be accepted, that would be
> > more
> > useful.
> 
> Hello James,
> 
> Several patch series have been posted by different authors. Some of 
> these patch series have already been reworked several times for 
> different kernel versions. I think a meeting in person would make it 
> easier to discuss which patch series to take upstream first and 
> thereby avoid to have to keep reworking these patch series against an
> evolving target API. These patch series are:
> 
> * Christoph Hellwig, [RFC] simplify session shutdown, January 14 
> (http://thread.gmane.org/gmane.linux.scsi.target.devel/11135).
> * Nicholas Bellinger, [PATCH 0/2] target: Fix LUN_RESET active I/O +
> TMR 
> handling, January 12, 2016 
> (http://thread.gmane.org/gmane.linux.scsi.target.devel/11097).
> * Bart Van Assche,  [PATCH 00/21] SCSI target patches for kernel
> v4.5, 
> January 5 (
> http://thread.gmane.org/gmane.linux.scsi.target.devel/10905)

So you don't really want a topic, you want a BoF?  We can do that.

James

Re: [LSF/MM TOPIC] LIO/SCST Merger

[Nicholas A. Bellinger]

On Wed, 2016-01-27 at 09:54 -0800, Bart Van Assche wrote:
> Last year, during the 2015 LSF/MM summit, it has been decided that the 
> LIO/SCST merger project should proceed by sending the functionality 
> upstream that is present in SCST but not yet in LIO. This will help to 
> reduce the workload of target driver maintainers that maintain a version 
> of their target driver for both LIO and SCST (QLogic FC and FCoE target 
> drivers, Emulex FC and FCoE target drivers, RDMA iSER target driver, 
> RDMA SRP target driver, ...). My proposal is to organize a session 
> during which the following is discussed:
> * Which patches are already upstream in the context of the LIO/SCST 
> merger project.
> * About which patches there is agreement but that are not yet upstream.
> * To discuss how to proceed from here and what to address first.

No, just no.  If you've not been able to articulate the specifics of
what you're talking about to the list by now, it's never going to
happen.

You'll recall last year how things unfolded at LSF.  You started
comparing data structure TMR member names of no consequence to a larger
LSF audience, and quickly tried to pivot into a discussion about adding
hooks to LIO fabric drivers for your own out-of-tree nastiness.

I really fail to see how that helps LIO or upstream.  To repeat.  I'll
not allow SCST's out-of-tree legacy requirements to limit LIO's future
in upstream, and if you or your employer is still trying to get
enterprise distros to listen to that nonsense behind the scenes, then
please stop wasting everybody's time.

Bart, I really want to believe you and your employer have good
intentions for LIO.  However, being one of it's largest detractors in
the past means that you have to really put your best foot forward on
your interaction with the LIO community.

However, your inability to ask questions before acting, refusing to
answer to all feedback on reviews for changes of substance, and not
following the expected patch review progress without repeatably leading
yourself and others down the wrong path really makes me start to
question your intentions, or at least your abilities as a kernel
contributor.

Also, you've not managed to merge any of the outstanding ib_srpt fixes
from the last year, which brings us to a grad total of 6 small patches
since the original merge of ib_srpt in Oct 2011.

# git log --author=Bart --oneline -- drivers/infiniband/ulp/srpt/
19f5729 IB/srpt: Fix the RDMA completion handlers
ba92999 target: Minimize SCSI header #include directives
2fe6e72 ib_srpt: Remove set-but-not-used variables
649ee05 target: Move task tag into struct se_cmd + support 64-bit tags
afc1660 target: Remove first argument of target_{get,put}_sess_cmd()
ab477c1 srp-target: Retry when QP creation fails with ENOMEM

That's really a terrible record.

So until you're able to demonstrate publicly to me and the LIO community
that you do have good intentions, and not trying to rehash the same
tired old nonsense and willful ignorance, please stop throwing out these
generic topics as a branding exercise.

There are much more interesting and important topics at LSF to discuss.

Re: [LSF/MM TOPIC] LIO/SCST Merger

[Christoph Hellwig]

Everyone calm down.

I'm going to downvote this topic just like last year with my PC hat on
as I think it's a) not relevant or usefully discussable at LSF and b)
framed the wrong way.

But let's forget about unification and think about fixing up lose ends
and looking at other implementations and other preople experiences
here.  While I'd never want to take SCST as a whole into the kernel tree
there are plenty of good idea to look at, and Bart has been trying for
quite a while to merge a lot of the concepts into the in-kernel SCSI
target stack and has meet an incredibly hostility.  And I have the
impression as lot of that is due to him beeing Bart - I've done some
quite similar things where I took concepts from SCST or other
implementations and opnly meet minor if any resistance.

Maybe we should have a discussion about equalt treatment on the
target-devel list instead? :)

Re: [LSF/MM TOPIC] LIO/SCST Merger

[Sagi Grimberg]

> I'm going to downvote this topic just like last year with my PC hat on
> as I think it's a) not relevant or usefully discussable at LSF and b)
> framed the wrong way.

I'm not sure LSF is the right platform, but I gotta say that this
thread indicates that there's bad blood going around here and it
needs to sorted out.

Re: [Lsf-pc] [LSF/MM TOPIC] LIO/SCST Merger

[James Bottomley]

On Thu, 2016-01-28 at 18:24 +0200, Sagi Grimberg wrote:
> > I'm going to downvote this topic just like last year with my PC hat 
> > on as I think it's a) not relevant or usefully discussable at LSF 
> > and b) framed the wrong way.
> 
> I'm not sure LSF is the right platform, but I gotta say that this
> thread indicates that there's bad blood going around here and it
> needs to sorted out.

OK, could we make this more concrete.  "Bad blood" or perhaps bias
against people ideas or patches is easy to allege, especially if you
think it will get your patches in, and, in the current climate, easy to
make stick because you can pin this on a maintainer who's simply having
a bad day or is overloaded.

Do you have an example of a set of patches you think have been
unreasonably rejected?  Probably discussing the issues before a wider
audience will help solve them before you drag someone to the "right
forum" (to me, those words conjure visions of pitch forks, stocks and
pilliories, but that's probably because the original version of
Frankenstien was on recently).

James

Re: [LSF/MM TOPIC] LIO/SCST Merger

[Bart Van Assche]

On 01/27/16 22:37, Nicholas A. Bellinger wrote:
> [ ... ]

Hi Nic,

Since in the most recent years all my communication to you was neutral 
and professional in tone it is not clear to me why you wrote such a 
misleading and unfair e-mail. Anyway, I would like to point out that the 
following information is missing from your e-mail:
- That last year the storage HBA vendors and Linux distributor
   representatives who attended my session about this topic where
   unanimously enthusiastic about my proposal. You were the only
   attendee who was not (yet?) enthusiast.
- That I am working on sending the ib_srpt patches upstream you
   referred to in your e-mail and that a first version of that patch
   series has already been posted on the linux-rdma mailing list.
- Although five years ago some SCST users switched to LIO, recently
   several LIO users switched back to SCST because the latter is still
   more stable and easier to configure than LIO. In other words, it is
   in your own interest to help the LIO patches upstream that I posted
   recently.
- One of the reasons that the LIO core patches I'm working on are not
   yet upstream is because of how long it takes before you as a
   maintainer provide feedback. The first version of my patch to make
   ABORT and LUN RESET handling synchronous was posted on October 12,
   2015. It took until November 15, 2015 before I received the first
   feedback from you for that patch.

Bart.

Re: [LSF/MM TOPIC] LIO/SCST Merger

[Alex Gorbachev]

$0.02 from the heavy user of both frameworks in mission critical
clinical environment, we tremendously appreciate the contribution of
all developers, maintainers and organizers, the innovative and
versatile approach of LIO (especially the Ceph back end for us) and
the stability and automation of SCST.  I hope the great work you guys
are doing is able to complement each other and result in powerful
solutions that will allow us, Mission Critical users, designers and
integrators, to offer a truly competitive options to large box SANs.

What you are doing makes a difference every day.

--
Alex Gorbachev
Storcium


On Thu, Jan 28, 2016 at 10:34 AM, Bart Van Assche
<bart.vanassche@sandisk.com> wrote:
> On 01/27/16 22:37, Nicholas A. Bellinger wrote:
>>
>> [ ... ]
>
>
> Hi Nic,
>
> Since in the most recent years all my communication to you was neutral and
> professional in tone it is not clear to me why you wrote such a misleading
> and unfair e-mail. Anyway, I would like to point out that the following
> information is missing from your e-mail:
> - That last year the storage HBA vendors and Linux distributor
>   representatives who attended my session about this topic where
>   unanimously enthusiastic about my proposal. You were the only
>   attendee who was not (yet?) enthusiast.
> - That I am working on sending the ib_srpt patches upstream you
>   referred to in your e-mail and that a first version of that patch
>   series has already been posted on the linux-rdma mailing list.
> - Although five years ago some SCST users switched to LIO, recently
>   several LIO users switched back to SCST because the latter is still
>   more stable and easier to configure than LIO. In other words, it is
>   in your own interest to help the LIO patches upstream that I posted
>   recently.
> - One of the reasons that the LIO core patches I'm working on are not
>   yet upstream is because of how long it takes before you as a
>   maintainer provide feedback. The first version of my patch to make
>   ABORT and LUN RESET handling synchronous was posted on October 12,
>   2015. It took until November 15, 2015 before I received the first
>   feedback from you for that patch.
>
> Bart.
>
> --
> To unsubscribe from this list: send the line "unsubscribe target-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [LSF/MM TOPIC] LIO/SCST Merger

[Vladislav Bolkhovitin]

Nicholas A. Bellinger wrote on 01/27/2016 10:36 PM:
> On Wed, 2016-01-27 at 09:54 -0800, Bart Van Assche wrote:
>> Last year, during the 2015 LSF/MM summit, it has been decided that the 
>> LIO/SCST merger project should proceed by sending the functionality 
>> upstream that is present in SCST but not yet in LIO. This will help to 
>> reduce the workload of target driver maintainers that maintain a version 
>> of their target driver for both LIO and SCST (QLogic FC and FCoE target 
>> drivers, Emulex FC and FCoE target drivers, RDMA iSER target driver, 
>> RDMA SRP target driver, ...). My proposal is to organize a session 
>> during which the following is discussed:
>> * Which patches are already upstream in the context of the LIO/SCST 
>> merger project.
>> * About which patches there is agreement but that are not yet upstream.
>> * To discuss how to proceed from here and what to address first.
> 
> No, just no.  If you've not been able to articulate the specifics of
> what you're talking about to the list by now, it's never going to
> happen.
> 
> You'll recall last year how things unfolded at LSF.  You started
> comparing data structure TMR member names of no consequence to a larger
> LSF audience, and quickly tried to pivot into a discussion about adding
> hooks to LIO fabric drivers for your own out-of-tree nastiness.
> 
> I really fail to see how that helps LIO or upstream.  To repeat.  I'll
> not allow SCST's out-of-tree legacy requirements to limit LIO's future
> in upstream, and if you or your employer is still trying to get
> enterprise distros to listen to that nonsense behind the scenes, then
> please stop wasting everybody's time.
> 
> Bart, I really want to believe you and your employer have good
> intentions for LIO.  However, being one of it's largest detractors in
> the past means that you have to really put your best foot forward on
> your interaction with the LIO community.
> 
> However, your inability to ask questions before acting, refusing to
> answer to all feedback on reviews for changes of substance, and not
> following the expected patch review progress without repeatably leading
> yourself and others down the wrong path really makes me start to
> question your intentions, or at least your abilities as a kernel
> contributor.
> 
> Also, you've not managed to merge any of the outstanding ib_srpt fixes
> from the last year, which brings us to a grad total of 6 small patches
> since the original merge of ib_srpt in Oct 2011.
> 
> # git log --author=Bart --oneline -- drivers/infiniband/ulp/srpt/
> 19f5729 IB/srpt: Fix the RDMA completion handlers
> ba92999 target: Minimize SCSI header #include directives
> 2fe6e72 ib_srpt: Remove set-but-not-used variables
> 649ee05 target: Move task tag into struct se_cmd + support 64-bit tags
> afc1660 target: Remove first argument of target_{get,put}_sess_cmd()
> ab477c1 srp-target: Retry when QP creation fails with ENOMEM
> 
> That's really a terrible record.
> 
> So until you're able to demonstrate publicly to me and the LIO community
> that you do have good intentions, and not trying to rehash the same
> tired old nonsense and willful ignorance, please stop throwing out these
> generic topics as a branding exercise.
> 
> There are much more interesting and important topics at LSF to discuss.

While I'm generally refraining from feeding trolls, don't you think that a person who
has contributed you one of the major drivers and continues making such important
contributions (for free!) trying to bring (eventually, after how many years?) LIO
reliability to something you can compare to SCST, deserves a little more respect?

Vlad