Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Doug Ledford]

On Thu, 2015-04-16 at 16:18 -0600, Jason Gunthorpe wrote:
 On Thu, Apr 16, 2015 at 06:03:19PM -0400, Doug Ledford wrote:
   AFAIK, capturing provided tags is considered best practice as a way to
   recognize and retain contributors.
  
  Agreed.  I'll double check them tomorrow.
 
 These are two I noticed from memory:
 
 http://permalink.gmane.org/gmane.linux.drivers.rdma/24423
 https://lkml.org/lkml/2015/4/15/9 
 
 Jason

Those have been fixed, and a few additional items have been added to the
overall set and pushed to my github.

New items since the last push:

Jason's fix to the CMA for IPv4/IPv6 canonization
Hariprasad's series to iw_cxgb4
Tatyana's and Steve's series for iWARP portmapper address resolution

git://github.com/dledford/linux.git for-4.1

-- 
Doug Ledford dledf...@redhat.com
  GPG KeyID: 0E572FDD




signature.asc
Description: This is a digitally signed message part

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Roland Dreier]

On Wed, Apr 22, 2015 at 7:43 AM, Doug Ledford dledf...@redhat.com wrote:
 New items since the last push:

 Jason's fix to the CMA for IPv4/IPv6 canonization
 Hariprasad's series to iw_cxgb4
 Tatyana's and Steve's series for iWARP portmapper address resolution

I just sent the previous batch, since it is late in the merge window
and I didn't want to send things immediately without giving
linux-next, 0-day builds etc a chance to catch problems.

I will pick these up and send to Linus around Friday.

 - R.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Doug Ledford]

On Wed, 2015-04-22 at 10:10 -0700, Roland Dreier wrote:
 On Wed, Apr 22, 2015 at 7:43 AM, Doug Ledford dledf...@redhat.com wrote:
  New items since the last push:
 
  Jason's fix to the CMA for IPv4/IPv6 canonization
  Hariprasad's series to iw_cxgb4
  Tatyana's and Steve's series for iWARP portmapper address resolution
 
 I just sent the previous batch, since it is late in the merge window
 and I didn't want to send things immediately without giving
 linux-next, 0-day builds etc a chance to catch problems.
 
 I will pick these up and send to Linus around Friday.
 
  - R.

That works.  Thanks!

-- 
Doug Ledford dledf...@redhat.com
  GPG KeyID: 0E572FDD




signature.asc
Description: This is a digitally signed message part

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Or Gerlitz]

On Fri, Apr 17, 2015 at 1:03 AM, Doug Ledford dledf...@redhat.com wrote:
 On Thu, 2015-04-16 at 15:37 -0600, Jason Gunthorpe wrote:
 On Fri, Apr 17, 2015 at 12:26:47AM +0300, Or Gerlitz wrote:
  On Thu, Apr 16, 2015 at 11:13 PM, Jason Gunthorpe
  jguntho...@obsidianresearch.com wrote:
   On Wed, Apr 15, 2015 at 08:39:13AM -0400, Doug Ledford wrote:
  
   Let’s take this as a starting point.  If there are other patches
   people think should make 4.1, please bring them to my attention and
   I’ll add them for review and possible addition to the list.
  
   git://github.com/dledford/linux.git for-4.1
  
   I noticed a few patches didn't get Reviewed-By's etc from the mailing
   list annotated..
 
  Every patch need not have a Reviewed-By annotation, it's perfectly up
  to the maintainer judgement to make sure there was either consensus,

 More clearly: There were several patches where a Reviewed-By/etc was
 *provided* on-list but did not get captured in the git commit.

 Sure, that's what I figured you meant.  That most likely means that I
 pulled the bundle from patchworks before their review was captured.  It
 means I would need to either re-pull the bundle or manually add the
 review.

 AFAIK, capturing provided tags is considered best practice as a way to
 recognize and retain contributors.

 Agreed.  I'll double check them tomorrow.

Doug,

Seems like Roland isn't around to carry the rdma pull request for 4.1 ...

I assume the most safe way to do that would be ask Dave Miller to pull
the patches from your tree into net-next ASAP, next, have them sit
there for 1-2 days to pass linux-next etc auto merge tests, and then
have Dave to send a pull request. Dave, I hope it would be OK from you
to help us here with the 4.1-rc1 bits. For 4.2 and 4.1-rc  1 Doug
will should be ready for sending pull request directly to Linus.

Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Or Gerlitz]

On Fri, Apr 17, 2015 at 8:03 PM, Roland Dreier rol...@kernel.org wrote:
 On Fri, Apr 17, 2015 at 4:15 AM, Or Gerlitz gerlitz...@gmail.com wrote:
 Seems like Roland isn't around to carry the rdma pull request for 4.1 ...

 Why do you ignore my emails (I see no reply to
 http://www.spinics.net/lists/linux-rdma/msg24194.html) and jump to
 this conclusion?

Sorry, I misread where things are, I was under the impression that all
was in place and expected you to pull things after you made this post
@ Wednesday http://www.spinics.net/lists/linux-rdma/msg24191.html, NM,
we're on track. Thanks a lot for driving the bits for the 4.1 merge
window.

 I will send a pull request for what is in Doug's tree (and also in my tree).

cool
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Roland Dreier]

On Apr 11, 2015 12:28 PM, Or Gerlitz gerlitz...@gmail.com wrote:

 If taking off the maintainer hat would get you some free/spare cycles,
 maybe you could resume posting in the digitalvampire blog and/or
 participate in the upstreamming of soft-RoCE driver? some folks here
 are working on this, so if you're interested, let me know...

Thank you very much for the direction.  I'm OK figuring out what to do
for myself though.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Roland Dreier]

On Fri, Apr 17, 2015 at 4:15 AM, Or Gerlitz gerlitz...@gmail.com wrote:
 Seems like Roland isn't around to carry the rdma pull request for 4.1 ...

Why do you ignore my emails (I see no reply to
http://www.spinics.net/lists/linux-rdma/msg24194.html) and jump to
this conclusion?

I will send a pull request for what is in Doug's tree (and also in my tree).
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Doug Ledford]

On Thu, 2015-04-16 at 15:37 -0600, Jason Gunthorpe wrote:
 On Fri, Apr 17, 2015 at 12:26:47AM +0300, Or Gerlitz wrote:
  On Thu, Apr 16, 2015 at 11:13 PM, Jason Gunthorpe
  jguntho...@obsidianresearch.com wrote:
   On Wed, Apr 15, 2015 at 08:39:13AM -0400, Doug Ledford wrote:
  
   Let’s take this as a starting point.  If there are other patches
   people think should make 4.1, please bring them to my attention and
   I’ll add them for review and possible addition to the list.
  
   git://github.com/dledford/linux.git for-4.1
  
   I noticed a few patches didn't get Reviewed-By's etc from the mailing
   list annotated..
  
  Every patch need not have a Reviewed-By annotation, it's perfectly up
  to the maintainer judgement to make sure there was either consensus,
 
 More clearly: There were several patches where a Reviewed-By/etc was
 *provided* on-list but did not get captured in the git commit.

Sure, that's what I figured you meant.  That most likely means that I
pulled the bundle from patchworks before their review was captured.  It
means I would need to either re-pull the bundle or manually add the
review.

 AFAIK, capturing provided tags is considered best practice as a way to
 recognize and retain contributors.

Agreed.  I'll double check them tomorrow.

-- 
Doug Ledford dledf...@redhat.com
  GPG KeyID: 0E572FDD




signature.asc
Description: This is a digitally signed message part

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Jason Gunthorpe]

On Fri, Apr 17, 2015 at 12:26:47AM +0300, Or Gerlitz wrote:
 On Thu, Apr 16, 2015 at 11:13 PM, Jason Gunthorpe
 jguntho...@obsidianresearch.com wrote:
  On Wed, Apr 15, 2015 at 08:39:13AM -0400, Doug Ledford wrote:
 
  Let’s take this as a starting point.  If there are other patches
  people think should make 4.1, please bring them to my attention and
  I’ll add them for review and possible addition to the list.
 
  git://github.com/dledford/linux.git for-4.1
 
  I noticed a few patches didn't get Reviewed-By's etc from the mailing
  list annotated..
 
 Every patch need not have a Reviewed-By annotation, it's perfectly up
 to the maintainer judgement to make sure there was either consensus,

More clearly: There were several patches where a Reviewed-By/etc was
*provided* on-list but did not get captured in the git commit.

AFAIK, capturing provided tags is considered best practice as a way to
recognize and retain contributors.

Jason
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Jason Gunthorpe]

On Wed, Apr 15, 2015 at 08:39:13AM -0400, Doug Ledford wrote:

 Let’s take this as a starting point.  If there are other patches
 people think should make 4.1, please bring them to my attention and
 I’ll add them for review and possible addition to the list.
 
 git://github.com/dledford/linux.git for-4.1

I noticed a few patches didn't get Reviewed-By's etc from the mailing
list annotated..

Jason
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Or Gerlitz]

On Thu, Apr 16, 2015 at 11:13 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
 On Wed, Apr 15, 2015 at 08:39:13AM -0400, Doug Ledford wrote:

 Let’s take this as a starting point.  If there are other patches
 people think should make 4.1, please bring them to my attention and
 I’ll add them for review and possible addition to the list.

 git://github.com/dledford/linux.git for-4.1

 I noticed a few patches didn't get Reviewed-By's etc from the mailing
 list annotated..

Every patch need not have a Reviewed-By annotation, it's perfectly up
to the maintainer judgement to make sure there was either consensus,
or that he/she accepts that despite (say) one person not liking them
-- here the 2nd type doesn't exist -- as Doug note spelled, these are
the patches

 My IPoIB changes

was reviewed by Erez

 Erez’s IPoIB changes

was reviewed by Doug

 Or’s mlx4 changes

these are Yishai's patches, driver ones, we applied your feedback BTW

 Sagi’s iSER changes

posted by the driver maintainer, a co-maintainer (me) reviewed them

 The two patch fixup to the CVE issue

have reviewed by

 A few other miscellaneous patches

etc
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Sagi Grimberg]

On 4/15/2015 4:07 PM, Doug Ledford wrote:



On Apr 15, 2015, at 9:02 AM, Sagi Grimberg sa...@dev.mellanox.co.il wrote:

On 4/15/2015 3:39 PM, Doug Ledford wrote:



On Apr 15, 2015, at 7:43 AM, Pradeep Kankipati pradeep.kankip...@emulex.com 
wrote:

We at Emulex, have been working with Doug on the RH inboxing effort for a while 
and feel this just makes complete sense for him to take on this role for all 
the reasons mentioned. Personally too I feel he is an excellent choice.


Regardless of what we end up doing long term, Roland is out at the moment, so 
4.1 is happening more or less without him :-/

I went ahead and put together a 4.1 branch and pulled the patches I thought 
were ready. That’s been pushed to my github.  I know it’s hard to get things 
done without being able to make sure your patches apply cleanly.  For instance, 
the namespace patches aren’t included, and that’s at least partially because 
they didn’t apply cleanly any more.  So, I included the following series of 
patches:

My IPoIB changes
Erez’s IPoIB changes
Or’s mlx4 changes
Sagi’s iSER changes


Hey Doug,

Did you pull v3?


Yes.


Great, thanks.

Sagi.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Doug Ledford]

 On Apr 15, 2015, at 9:02 AM, Sagi Grimberg sa...@dev.mellanox.co.il wrote:
 
 On 4/15/2015 3:39 PM, Doug Ledford wrote:
 
 On Apr 15, 2015, at 7:43 AM, Pradeep Kankipati 
 pradeep.kankip...@emulex.com wrote:
 
 We at Emulex, have been working with Doug on the RH inboxing effort for a 
 while and feel this just makes complete sense for him to take on this role 
 for all the reasons mentioned. Personally too I feel he is an excellent 
 choice.
 
 Regardless of what we end up doing long term, Roland is out at the moment, 
 so 4.1 is happening more or less without him :-/
 
 I went ahead and put together a 4.1 branch and pulled the patches I thought 
 were ready. That’s been pushed to my github.  I know it’s hard to get things 
 done without being able to make sure your patches apply cleanly.  For 
 instance, the namespace patches aren’t included, and that’s at least 
 partially because they didn’t apply cleanly any more.  So, I included the 
 following series of patches:
 
 My IPoIB changes
 Erez’s IPoIB changes
 Or’s mlx4 changes
 Sagi’s iSER changes
 
 Hey Doug,
 
 Did you pull v3?

Yes.

—
Doug Ledford dledf...@redhat.com
GPG Key ID: 0E572FDD







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Sagi Grimberg]

On 4/15/2015 3:39 PM, Doug Ledford wrote:



On Apr 15, 2015, at 7:43 AM, Pradeep Kankipati pradeep.kankip...@emulex.com 
wrote:

We at Emulex, have been working with Doug on the RH inboxing effort for a while 
and feel this just makes complete sense for him to take on this role for all 
the reasons mentioned. Personally too I feel he is an excellent choice.


Regardless of what we end up doing long term, Roland is out at the moment, so 
4.1 is happening more or less without him :-/

I went ahead and put together a 4.1 branch and pulled the patches I thought 
were ready.  That’s been pushed to my github.  I know it’s hard to get things 
done without being able to make sure your patches apply cleanly.  For instance, 
the namespace patches aren’t included, and that’s at least partially because 
they didn’t apply cleanly any more.  So, I included the following series of 
patches:

My IPoIB changes
Erez’s IPoIB changes
Or’s mlx4 changes
Sagi’s iSER changes


Hey Doug,

Did you pull v3?

Sagi.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Doug Ledford]

 On Apr 15, 2015, at 7:43 AM, Pradeep Kankipati pradeep.kankip...@emulex.com 
 wrote:
 
 We at Emulex, have been working with Doug on the RH inboxing effort for a 
 while and feel this just makes complete sense for him to take on this role 
 for all the reasons mentioned. Personally too I feel he is an excellent 
 choice.

Regardless of what we end up doing long term, Roland is out at the moment, so 
4.1 is happening more or less without him :-/

I went ahead and put together a 4.1 branch and pulled the patches I thought 
were ready.  That’s been pushed to my github.  I know it’s hard to get things 
done without being able to make sure your patches apply cleanly.  For instance, 
the namespace patches aren’t included, and that’s at least partially because 
they didn’t apply cleanly any more.  So, I included the following series of 
patches:

My IPoIB changes
Erez’s IPoIB changes
Or’s mlx4 changes
Sagi’s iSER changes
The two patch fixup to the CVE issue
A few other miscellaneous patches

Let’s take this as a starting point.  If there are other patches people think 
should make 4.1, please bring them to my attention and I’ll add them for review 
and possible addition to the list.

git://github.com/dledford/linux.git for-4.1


 Thanks,
 Pradeep
 --
 
 -Original Message-
 From: linux-rdma-ow...@vger.kernel.org 
 [mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of ira.weiny
 Sent: Wednesday, April 15, 2015 5:13 AM
 To: Doug Ledford
 Cc: Jason Gunthorpe; Yann Droneaud; Hefty, Sean; Roland Dreier; Hal 
 Rosenstock; David Miller; Or Gerlitz; linux-rdma@vger.kernel.org; 
 ta...@mellanox.com; Amir Vadai; Sagi Grimberg; Haggai Eran; Shachar Raindel
 Subject: Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 
 changes in virtual GID management)
 
 On Mon, Apr 13, 2015 at 01:14:40PM -0400, Doug Ledford wrote:
 
 On Apr 13, 2015, at 12:42 PM, Jason Gunthorpe
 jguntho...@obsidianresearch.com wrote:
 
 On Sun, Apr 12, 2015 at 07:16:33PM +0200, Yann Droneaud wrote:
 
 That would make sense to have someone like Doug or Jason being the
 potential successors to Roland in order to keep InfiniBand
 subsystem vendor neutrality.
 
 Several people have been asking me privately, I am looking into if
 this would be possible or not.
 
 
 Same here (having been asked privately to look into doing this).
 FWIW,
 Red Hat has agreed that they are willing to allow me to transition my job to 
 a full time upstream focused position (as of now, I work on upstream around 
 my deliverables inside the company).
 
 
 I think Doug and Jason are both qualified.
 
 However, with Red Hat willing to dedicate Doug full time I think that makes 
 Doug an ideal candidate considering the patch load.
 
 Ira
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-rdma in the 
 body of a message to majord...@vger.kernel.org More majordomo info at  
 http://vger.kernel.org/majordomo-info.html
 

—
Doug Ledford dledf...@redhat.com
GPG Key ID: 0E572FDD







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Roland Dreier]

On Wed, Apr 15, 2015 at 5:39 AM, Doug Ledford dledf...@redhat.com wrote:
 Regardless of what we end up doing long term, Roland is out at the moment, so 
 4.1 is happening more or less without him :-/

Sorry.  I am back at work now.

 I went ahead and put together a 4.1 branch and pulled the patches I thought 
 were ready.  That’s been pushed to my github.

Thanks, I will pick this up and put it in my kernel.org tree so we get
0-day testing to make sure everything builds etc.

 - R.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Or Gerlitz]

On Wed, Apr 15, 2015 at 8:13 PM, Roland Dreier rol...@kernel.org wrote:
 On Wed, Apr 15, 2015 at 5:39 AM, Doug Ledford dledf...@redhat.com wrote:
 Regardless of what we end up doing long term, Roland is out at the moment, 
 so 4.1 is happening more or less without him :-/

 Sorry.  I am back at work now.

 I went ahead and put together a 4.1 branch and pulled the patches I thought 
 were ready.  That’s been pushed to my github.

 Thanks, I will pick this up and put it in my kernel.org tree so we get
 0-day testing to make sure everything builds etc.

Roland, see my Re: RDMA patches for 4.1 note, there are two
conflicts with net-next mlx4 commits.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Steve Wise]

 -Original Message-
 From: linux-rdma-ow...@vger.kernel.org 
 [mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Doug Ledford
 Sent: Monday, April 13, 2015 12:15 PM
 To: Jason Gunthorpe
 Cc: Yann Droneaud; Hefty, Sean; Roland Dreier; Hal Rosenstock 
 (h...@dev.mellanox.co.il); David Miller; Or Gerlitz; Weiny, Ira; linux-
 r...@vger.kernel.org; ta...@mellanox.com; Amir Vadai; Sagi Grimberg; Haggai 
 Eran; Shachar Raindel
 Subject: Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 
 changes in virtual GID management)
 
 
  On Apr 13, 2015, at 12:42 PM, Jason Gunthorpe 
  jguntho...@obsidianresearch.com wrote:
 
  On Sun, Apr 12, 2015 at 07:16:33PM +0200, Yann Droneaud wrote:
 
  That would make sense to have someone like Doug or Jason being the
  potential successors to Roland in order to keep InfiniBand subsystem
  vendor neutrality.
 
  Several people have been asking me privately, I am looking into if
  this would be possible or not.
 
 
 Same here (having been asked privately to look into doing this).  FWIW, Red 
 Hat has agreed that they are willing to allow me to transition
 my job to a full time upstream focused position (as of now, I work on 
 upstream around my deliverables inside the company).
 

Doug, I think you're a good fit for the RDMA maintainer if you're willing.

Steve.



--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Or Gerlitz]

On Mon, Apr 13, 2015 at 8:53 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:

 Or, I was also a bit annoyed by your last email, the tone just seemed
 inappropriate/in-gracious for the situation.

I made a full clarification and wait to see Sean's response. Sean is
doing excellent work over the years, now something is on hold for
months w.o any clear reason and I complain.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Or Gerlitz]

On Mon, Apr 13, 2015 at 8:53 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:

 As far as patches go, you keep asking for reviews, but where are the
 reviews from Mellanox? I count 45 @mellanox folks who contributed to
 the kernel, but I wouldn't have guessed that based on mailing
 list participation.

Jason,

Making things more precise... glasses have two halves, namely:

on the RDMA Storage side of things, Sagi Grimberg is doing tons of
rdma kernel work, besides being a  maintainer of both iSER target and
Initiator drivers AND top contributor to both, he reviews practically
every SRP patch sent to this list and many if not most of the NFS RDMA
patches sent here. This can be checked with Bart Van Assche and Chuck
Lever, see also [1]

on the IPoIB side of things, Erez Shitrit is reviewing the IPoIB
patches sent here. Specifically, he spent endless hours reviewing the
3-4 rounds of the fixes Doug sent in the last months, not only he
reviewed them, he took them into regression on our systems and showed
Doug again and again where things break, till the point where that
worked.

Hal Rosenstock is reviewing every patch which related to the MAD layer.

Haggai Eran, Matan Barak and Shachar Raindel interacted with Yann on
his comments and patches he sent to fix and enhance things around ODP
and uverbs extensions.

Jack Morgenstein, Eli Cohen and Amir Vadai constantly review patches
and address questions and issues raised by other parties for the
low-level mellanox drivers.

ETC, and I will not speak on myself, see for yourself where/when I
commented on patches sent by other members of this community.

 I see patches from Yann, Michael, Ira, and Yuval at least on the list
 that have seen general silence from your corner. That's just this last
 month or so.

Indeed, we can improve and some patch series didn't get enough review
from a @mellanox.com person, but by all means, the volume of back
reviews done here by mellanox folks goes way beyond what you describe.


 Look - the only way a subsystem can function properly is if all
 parties who want to continuously change the shared subystem core
 realise they have to contribute back review-hours and discussion
 leadership *AT LEAST* equal to what they receive.

Or.

[1] And all this is in parallel to his work @ the SCSI (previously MM
too) subsystem (SCSI target, iSCSI stack, Block MQ, etc) which enables
more indirect elements allowing for high performance RDMA storage to
shine.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Or Gerlitz]

On Mon, Apr 13, 2015 at 7:10 PM, Hefty, Sean sean.he...@intel.com wrote:
 Unfortunately, Sean -- you haven't provided for  2 months any
 feedback on the patches to the CM/CMA modules which you own/maintain
 for supporting name-spaces and such which are part of enabling proper
 RDMA support for containers.
 http://marc.info/?l=linux-netdevm=142366747608908w=2 This makes your
 co-maintainer position sort of problematic, BTW. Jason, any chance you
 can look on that?

 Linux does not pull anything from me directly.  My own patches to the code 
 that I supposedly maintain take *years* to get upstream.  I fail to see how 
 or why I need to review patches from a hostile party.

Sure, I know that Linus doesn't pull directly from you and also that
being a co-maintainer didn't help for when it took Roland 2-3 years to
pick your AF_IB patch series.

However, fact is that you are the author and maintainer of the CM and
RDMA_CM and over the years Roland didn't pick patches to these
components prior to your review and ack.

 two months ago we sent patch series which serves to add RDMA support to 
 containers and modify these two drivers, and not a word from you. This is 
 what missing. In the past it took you two hours to provide excellent 
 feedback, now something is broken out.

Sean, please speak up and explain who is hostile and why you think so,
BTW is that a personal comment?

Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Or Gerlitz]

On Sun, Apr 12, 2015 at 1:51 AM, Or Gerlitz gerlitz...@gmail.com wrote:
 On Thu, Apr 9, 2015 at 8:41 PM, Roland Dreier rol...@kernel.org wrote:
 On Tue, Apr 7, 2015 at 10:12 AM, Jason Gunthorpe
 jguntho...@obsidianresearch.com wrote:
 I don't think you understand how deep the problem Or is describing goes.

 [...Appropriate and correct critique...]

 This thread has made me realize that even as I am able to carve out
 more time to work on things like IB maintaintership, I no longer have
 the desire to spend my time maintaining the IB subsystem.  Since my
 current level of activity is clearly hurting the community, I've
 decided to step down as maintainer.

 I'm on a perhaps-unfortunately-timed vacation this week

 OK, but this is the last time for making these excuses (...)

 but to make the transition smooth, I'll handle the easy patches that are in 
 flight
 for 4.1 and then turn things over to the community for 4.2

 Sounds a fair plan to me.

 As we're just two days before the merge window is likely to open,
 could you please but ASAP immediately make what's queued @ your
 for-next branch private clone public?!

Roland,

So the merge window and there's still pretty much nothing in your
for-next branch. Could you please comment what are those easy patches
that you are going to put into the pull request for 4.1-rc1?!

If you don't intend to send anything, please say it too. So we can
send these already reviewed patches through other sub system
maintainers.

Or.


 currently, there's nothing there expect for one 4.- rc fix.

 Some from top of my head quick listing contains:

 1. Doug's IPoIB patches which finally passed full review and
 regression by Erez Shitrit @ Mellanox plus some review and testing by
 Intel/Ira
 http://marc.info/?t=14245649363r=1w=2

 2. Erez's followup patch series which few IPoIB changes and one mlx4 fix
 http://marc.info/?l=linux-rdmam=142797117721383w=2

 3. Yishai's mlx4 patches (where we started this thread)
 http://marc.info/?l=linux-rdmam=142788688230585w=2

 4. Sagi's iSER updates for 4.1 - which you acked but didn't make public

 Unfortunately, Sean -- you haven't provided for  2 months any
 feedback on the patches to the CM/CMA modules which you own/maintain
 for supporting name-spaces and such which are part of enabling proper
 RDMA support for containers.
 http://marc.info/?l=linux-netdevm=142366747608908w=2 This makes your
 co-maintainer position sort of problematic, BTW. Jason, any chance you
 can look on
 that?

 As for the core and driver RoCE changes, I see that there are comments
 from Sean and Bart, so the review isn't over yet.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[ira.weiny]

On Mon, Apr 13, 2015 at 01:14:40PM -0400, Doug Ledford wrote:
 
  On Apr 13, 2015, at 12:42 PM, Jason Gunthorpe 
  jguntho...@obsidianresearch.com wrote:
  
  On Sun, Apr 12, 2015 at 07:16:33PM +0200, Yann Droneaud wrote:
  
  That would make sense to have someone like Doug or Jason being the
  potential successors to Roland in order to keep InfiniBand subsystem
  vendor neutrality.
  
  Several people have been asking me privately, I am looking into if
  this would be possible or not.
  
 
 Same here (having been asked privately to look into doing this).  FWIW, Red 
 Hat has agreed that they are willing to allow me to transition my job to a 
 full time upstream focused position (as of now, I work on upstream around my 
 deliverables inside the company).
 

I think Doug and Jason are both qualified.

However, with Red Hat willing to dedicate Doug full time I think that makes
Doug an ideal candidate considering the patch load.

Ira

--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Or Gerlitz]

On 4/13/2015 8:14 PM, Doug Ledford wrote:

Same here (having been asked privately to look into doing this).  FWIW, Red Hat 
has agreed that they are willing to allow me to transition my job to a full 
time upstream focused position (as of now, I work on upstream around my 
deliverables inside the company).


Sounds very good. Doug, you've been around for long time and took active 
part in the evolution of this stack from the grounds and up to where we 
are today. Will be happy to see you picking the upstream maintainer seat 
for the for RDMA subsystem.


Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Hefty, Sean]

 Same here (having been asked privately to look into doing this).  FWIW,
 Red Hat has agreed that they are willing to allow me to transition my job
 to a full time upstream focused position (as of now, I work on upstream
 around my deliverables inside the company).

Excellent.  To me, this seems ideal.  Doug, since you have the broadest 
testing, regardless of who reviews the patches, would you be willing to stage 
the upstream changes starting with 4.2?

Does anyone (most importantly, Doug) have any issues with this? 

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Jason Gunthorpe]

On Mon, Apr 13, 2015 at 04:10:16PM +, Hefty, Sean wrote:
  Unfortunately, Sean -- you haven't provided for  2 months any
  feedback on the patches to the CM/CMA modules which you own/maintain
  for supporting name-spaces and such which are part of enabling proper
  RDMA support for containers.
  http://marc.info/?l=linux-netdevm=142366747608908w=2 This makes your
  co-maintainer position sort of problematic, BTW. Jason, any chance you
  can look on
  that?
 
 Linux does not pull anything from me directly.  My own patches to
 the code that I supposedly maintain take *years* to get upstream.  I
 fail to see how or why I need to review patches from a hostile
 party.

I expect the patch flow process will change..

We do actually need to all work together, so I urge you both to keep
talking and hash something out.

Or, I was also a bit annoyed by your last email, the tone just seemed
inappropriate/in-gracious for the situation.

As far as patches go, you keep asking for reviews, but where are the
reviews from Mellanox? I count 45 @mellanox folks who contributed to
the kernel, but I wouldn't have guessed that based on mailing
list participation.

I see patches from Yann, Michael, Ira, and Yuval at least on the list
that have seen general silence from your corner. That's just this last
month or so.

Look - the only way a subsystem can function properly is if all
parties who want to continuously change the shared subystem core
realise they have to contribute back review-hours and discussion
leadership *AT LEAST* equal to what they receive.

Jason
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Doug Ledford]

 On Apr 13, 2015, at 12:42 PM, Jason Gunthorpe 
 jguntho...@obsidianresearch.com wrote:
 
 On Sun, Apr 12, 2015 at 07:16:33PM +0200, Yann Droneaud wrote:
 
 That would make sense to have someone like Doug or Jason being the
 potential successors to Roland in order to keep InfiniBand subsystem
 vendor neutrality.
 
 Several people have been asking me privately, I am looking into if
 this would be possible or not.
 

Same here (having been asked privately to look into doing this).  FWIW, Red Hat 
has agreed that they are willing to allow me to transition my job to a full 
time upstream focused position (as of now, I work on upstream around my 
deliverables inside the company).

—
Doug Ledford dledf...@redhat.com
GPG Key ID: 0E572FDD







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Jason Gunthorpe]

On Sun, Apr 12, 2015 at 07:16:33PM +0200, Yann Droneaud wrote:

 That would make sense to have someone like Doug or Jason being the
 potential successors to Roland in order to keep InfiniBand subsystem
 vendor neutrality.

Several people have been asking me privately, I am looking into if
this would be possible or not.

Jason
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Hefty, Sean]

 Unfortunately, Sean -- you haven't provided for  2 months any
 feedback on the patches to the CM/CMA modules which you own/maintain
 for supporting name-spaces and such which are part of enabling proper
 RDMA support for containers.
 http://marc.info/?l=linux-netdevm=142366747608908w=2 This makes your
 co-maintainer position sort of problematic, BTW. Jason, any chance you
 can look on
 that?

Linux does not pull anything from me directly.  My own patches to the code that 
I supposedly maintain take *years* to get upstream.  I fail to see how or why I 
need to review patches from a hostile party.

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Yann Droneaud]

Hi,

Le vendredi 10 avril 2015 à 20:39 +, Hefty, Sean a écrit :
  I'm on a perhaps-unfortunately-timed vacation this week, but to make
  the transition smooth, I'll handle the easy patches that are in flight
  for 4.1, and then turn things over to the community for 4.2.  (Unless
  the feeling is that it's better for me to step down immediately — I
  have no problem doing that, I just don't want to leave people in the
  lurch)
 
 This transition plan makes sense to me.  I can dedicate more of my
 time helping to review kernel patches, at least for a couple of
 months.  Hal is listed as the other sub-maintainer.  He usually limits
 his input to the IB mgmt components, but maybe he can contribute more
 until we're over this hump?
 
 I'm not trying to volunteer anyone, but longer term, Doug appears to
 be in an ideal situation for maintaining the RDMA subtree.  Because of
 his position at RedHat, he has a strong interest in ensuring user
 space compatibility, can test across a wide range of devices, and
 needs to deal with long term maintenance issues.
 

That would make sense to have someone like Doug or Jason being the
potential successors to Roland in order to keep InfiniBand subsystem
vendor neutrality.

Regards.

-- 
Yann Droneaud
OPTEYA


--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Or Gerlitz]

On Thu, Apr 9, 2015 at 9:06 PM, Hefty, Sean sean.he...@intel.com wrote:
  This thread has made me realize that even as I am able to carve out
  more time to work on things like IB maintaintership, I no longer
  have the desire to spend my time maintaining the IB subsystem.
  Since my current level of activity is clearly hurting the community,
  I've decided to step down as maintainer.

 Thank you for all of your work over the years. I know that your
 technical skills and opinion have been widely appreciated and
 respected by the entire community.

 I concur, and I'd like to thank you for the personal time that you dedicated 
 to this project.

Here, too.

Roland, you made a terrific job, specially over your 1st five years @
duty (...) pushing IB upstream in the form of a modern / modular and
extendable kernel/user-space stack into Linux while designing it in a
way which easily  elegantly allowed for bringing in more RDMA
technologies such as RoCE and iWARP. I must also thank you personally
for the tons of coaching and review comments you provided me over the
years.

If taking off the maintainer hat would get you some free/spare cycles,
maybe you could resume posting in the digitalvampire blog and/or
participate in the upstreamming of soft-RoCE driver? some folks here
are working on this, so if you're interested, let me know...

Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Or Gerlitz]

On Thu, Apr 9, 2015 at 8:41 PM, Roland Dreier rol...@kernel.org wrote:
 On Tue, Apr 7, 2015 at 10:12 AM, Jason Gunthorpe
 jguntho...@obsidianresearch.com wrote:
 I don't think you understand how deep the problem Or is describing goes.

 [...Appropriate and correct critique...]

 This thread has made me realize that even as I am able to carve out
 more time to work on things like IB maintaintership, I no longer have
 the desire to spend my time maintaining the IB subsystem.  Since my
 current level of activity is clearly hurting the community, I've
 decided to step down as maintainer.

 I'm on a perhaps-unfortunately-timed vacation this week

OK, but this is the last time for making these excuses (...)

 but to make the transition smooth, I'll handle the easy patches that are in 
 flight
 for 4.1 and then turn things over to the community for 4.2

Sounds a fair plan to me.

As we're just two days before the merge window is likely to open,
could you please but ASAP immediately make what's queued @ your
for-next branch private clone public?!

currently, there's nothing there expect for one 4.- rc fix.

Some from top of my head quick listing contains:

1. Doug's IPoIB patches which finally passed full review and
regression by Erez Shitrit @ Mellanox plus some review and testing by
Intel/Ira
http://marc.info/?t=14245649363r=1w=2

2. Erez's followup patch series which few IPoIB changes and one mlx4 fix
http://marc.info/?l=linux-rdmam=142797117721383w=2

3. Yishai's mlx4 patches (where we started this thread)
http://marc.info/?l=linux-rdmam=142788688230585w=2

4. Sagi's iSER updates for 4.1 - which you acked but didn't make public

Unfortunately, Sean -- you haven't provided for  2 months any
feedback on the patches to the CM/CMA modules which you own/maintain
for supporting name-spaces and such which are part of enabling proper
RDMA support for containers.
http://marc.info/?l=linux-netdevm=142366747608908w=2 This makes your
co-maintainer position sort of problematic, BTW. Jason, any chance you
can look on
that?

As for the core and driver RoCE changes, I see that there are comments
from Sean and Bart, so the review isn't over yet.

Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Hefty, Sean]

 I'm on a perhaps-unfortunately-timed vacation this week, but to make
 the transition smooth, I'll handle the easy patches that are in flight
 for 4.1, and then turn things over to the community for 4.2.  (Unless
 the feeling is that it's better for me to step down immediately — I
 have no problem doing that, I just don't want to leave people in the
 lurch)

This transition plan makes sense to me.  I can dedicate more of my time helping 
to review kernel patches, at least for a couple of months.  Hal is listed as 
the other sub-maintainer.  He usually limits his input to the IB mgmt 
components, but maybe he can contribute more until we're over this hump?

I'm not trying to volunteer anyone, but longer term, Doug appears to be in an 
ideal situation for maintaining the RDMA subtree.  Because of his position at 
RedHat, he has a strong interest in ensuring user space compatibility, can test 
across a wide range of devices, and needs to deal with long term maintenance 
issues.

- Sean
N�r��yb�X��ǧv�^�)޺{.n�+{��ٚ�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

RE: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Weiny, Ira]

 
 On Tue, Apr 7, 2015 at 10:12 AM, Jason Gunthorpe
 jguntho...@obsidianresearch.com wrote:
  I don't think you understand how deep the problem Or is describing
  goes.
 
  [...Appropriate and correct critique...]
 
 This thread has made me realize that even as I am able to carve out more time
 to work on things like IB maintaintership, I no longer have the desire to 
 spend
 my time maintaining the IB subsystem.  Since my current level of activity is
 clearly hurting the community, I've decided to step down as maintainer.
 

I am sad to see you leave.  Without you InfiniBand would have never been 
accepted upstream at all.

Thank you for all the hard work,
Ira

N�r��yb�X��ǧv�^�)޺{.n�+{��ٚ�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Doug Ledford]

On Thu, 2015-04-09 at 10:41 -0700, Roland Dreier wrote:
 On Tue, Apr 7, 2015 at 10:12 AM, Jason Gunthorpe
 jguntho...@obsidianresearch.com wrote:
  I don't think you understand how deep the problem Or is describing
  goes.
 
  [...Appropriate and correct critique...]
 
 This thread has made me realize that even as I am able to carve out
 more time to work on things like IB maintaintership, I no longer have
 the desire to spend my time maintaining the IB subsystem.  Since my
 current level of activity is clearly hurting the community, I've
 decided to step down as maintainer.

Thank you for the long, thankless years of service.  I wish you the best
in whatever endeavors you choose to focus on!

-- 
Doug Ledford dledf...@redhat.com
  GPG KeyID: 0E572FDD




signature.asc
Description: This is a digitally signed message part

RE: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Hefty, Sean]

  This thread has made me realize that even as I am able to carve out
  more time to work on things like IB maintaintership, I no longer
  have the desire to spend my time maintaining the IB subsystem.
  Since my current level of activity is clearly hurting the community,
  I've decided to step down as maintainer.
 
 Thank you for all of your work over the years. I know that your
 technical skills and opinion have been widely appreciated and
 respected by the entire community.

I concur, and I'd like to thank you for the personal time that you dedicated to 
this project.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stepping down as maintainer (was Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management)

[Jason Gunthorpe]

On Thu, Apr 09, 2015 at 10:41:13AM -0700, Roland Dreier wrote:

 This thread has made me realize that even as I am able to carve out
 more time to work on things like IB maintaintership, I no longer
 have the desire to spend my time maintaining the IB subsystem.
 Since my current level of activity is clearly hurting the community,
 I've decided to step down as maintainer.

Thank you for all of your work over the years. I know that your
technical skills and opinion have been widely appreciated and
respected by the entire community.

Regards,
Jason
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Or Gerlitz]

On Sun, Apr 5, 2015 at 5:51 PM, Roland Dreier rol...@kernel.org wrote:
 On Sat, Apr 4, 2015 at 10:15 PM, Or Gerlitz gerlitz...@gmail.com wrote:
 Indeed. No maintainer voice makes it kind of impossible for
 discussions to converge. What happens over the last years is that when
 there's no easy consensus on matter Y, everyone stops breathing and
 wait to see what happens on the rc1 night, b/c Roland doesn't spell
 his view/preference (nor exposes his for-next branch till the last
 minute, see now) many times it seems more as coin flipping.

 To me this attitude shows a failure of the community.  If I need to
 make every decision, then that doesn't scale.  People can ask
 questions a lot more easily than I can answer them.

 In general if a consensus emerges, I'm pretty likely to trust it.  In
 particular, as Sean mentioned, I tend to trust vendors about low-level
 drivers, although of course I sometimes catch mistakes even then.

 But for changes that touch the core, when there's a disagreement, you
 can't expect me to be the one who always solves it.  I might have an
 opinion, but in a lot of cases, both sides might have a point and the
 only way forward is to come up with a new idea that works for
 everyone.  And I'm not smart enough to come up with that solution every time.

To make it a little more clear, my rc1 night note came to describe
situations where
not only that you didn't do the essential part of subsystem maintainer
job of dropping
a note on how you see things and where yo think the solution should be
going etc --
you went ahead and kind of randomly applied patch series for which there was no
consensus or bunch of open reviewer comments unanswered by the
submitters to your
for-next branch which you didn't post publicly and in  12h sent pull
request to Linus, crazy!!

BTW as we speak now (after rc7), the patches you already have for 4.1
(and there are such, as you acked
@ least one series on the list {BTW about 5y ago you stopped for 90%
of the cases to ack pactches
on the list, which is very frustrating for developers too}) aren't
public, you have a private clone which isn't
reflected at kernel.org

Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Jason Gunthorpe]

On Sun, Apr 05, 2015 at 04:46:26PM -0400, David Miller wrote:
 From: Roland Dreier rol...@kernel.org
 Date: Sun, 5 Apr 2015 07:51:08 -0700
 
  On Sat, Apr 4, 2015 at 10:15 PM, Or Gerlitz gerlitz...@gmail.com wrote:
  Indeed. No maintainer voice makes it kind of impossible for
  discussions to converge. What happens over the last years is that when
  there's no easy consensus on matter Y, everyone stops breathing and
  wait to see what happens on the rc1 night, b/c Roland doesn't spell
  his view/preference (nor exposes his for-next branch till the last
  minute, see now) many times it seems more as coin flipping.
  
  To me this attitude shows a failure of the community.  If I need to
  make every decision, then that doesn't scale.  People can ask
  questions a lot more easily than I can answer them.
 
 No, you need to step in and be the benevolent dictator when people
 have their thumbs up their asses and can't make up their minds,
 otherwise things grind to a halt.

Agree. 

As a community we don't need the subsystem maintainer to just applies
patches that don't have any discussion. Anyone can do that. We need
someone that guides potentially good patches to success and keeps the
whole code base on track.

I don't think you understand how deep the problem Or is describing
goes.

People have no idea what you want to see, what you will accept and
everytime they ask they get silence.

Or worse - remeber this?

http://www.spinics.net/lists/linux-rdma/msg21114.html

You drive-by-NAK'd Barts's patch and then completely ignored Doug's
follow up, the entire series just died out, and that patch is
still not applied.

This isn't a failure of the community.

There is a pretty clear expectation of what a subsystem maintainer
should do. Greg KH codified some of it in this presentation:

https://github.com/gregkh/presentation-linux-maintainer/blob/master/maintainer.pdf

Start at page 119:

What I will do for you:

 So, finally, you created the perfect patch
 series, took all review into account, and sent
 it correctly, without corrupting the patch.
 What should you expect from me, the
 subsystem maintainer?

Review your patch within 1-2 weeks

 Some subsystem maintainers try to get to
 patches even faster than this, but with travel
 and different conferences, the best that I
 can normally do is about 1-2 weeks.

 If I don't respond in that time frame, just ask
 what is going on. I have no problem with
 people asking about their patch status.
 Sometimes patches end up getting dropped
 on the floor accidentally, and if I'm being
 slow I have no problem with being called on
 it, so don't feel bad about checking up on it.

 But please wait 1-2 weeks, don't be rude and
 send a patch at night, and then in the
 morning send a complaining email asking
 why it wasn't reviewed already. This
 happens more than you want to know.

Offer semi-constructive criticism

Let you know the status of your patch

 I have a set of scripts that I got from Andrew
 Morton that will email you when I apply your
 patch to one of my development trees saying
 where it has been applied and when you can
 expect to see it show up in Linus's tree. There is
 no reason that all kernel maintainers shouldn't do
 this, and it's nice to see that more and more are.

 But, I know from personal experience, there are
 maintainers in this room that I send patches to
 and I never know what happens to them. A few
 months later I will see them show up in Linus's
 tree, usually after I forgot about them.

 That's not acceptable, and you should not allow
 this, push back on your subsystem maintainer to
 use something like this, to keep you informed.
 Andrew's scripts are public, as are my variations
 of them, for everyone to use.

Jason
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Roland Dreier]

On Sat, Apr 4, 2015 at 10:15 PM, Or Gerlitz gerlitz...@gmail.com wrote:
 Indeed. No maintainer voice makes it kind of impossible for
 discussions to converge. What happens over the last years is that when
 there's no easy consensus on matter Y, everyone stops breathing and
 wait to see what happens on the rc1 night, b/c Roland doesn't spell
 his view/preference (nor exposes his for-next branch till the last
 minute, see now) many times it seems more as coin flipping.

To me this attitude shows a failure of the community.  If I need to
make every decision, then that doesn't scale.  People can ask
questions a lot more easily than I can answer them.

In general if a consensus emerges, I'm pretty likely to trust it.  In
particular, as Sean mentioned, I tend to trust vendors about low-level
drivers, although of course I sometimes catch mistakes even then.

But for changes that touch the core, when there's a disagreement, you
can't expect me to be the one who always solves it.  I might have an
opinion, but in a lot of cases, both sides might have a point and the
only way forward is to come up with a new idea that works for
everyone.  And I'm not smart enough to come up with that solution
every time.

 - R.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[David Miller]

From: Roland Dreier rol...@kernel.org
Date: Sun, 5 Apr 2015 07:51:08 -0700

 On Sat, Apr 4, 2015 at 10:15 PM, Or Gerlitz gerlitz...@gmail.com wrote:
 Indeed. No maintainer voice makes it kind of impossible for
 discussions to converge. What happens over the last years is that when
 there's no easy consensus on matter Y, everyone stops breathing and
 wait to see what happens on the rc1 night, b/c Roland doesn't spell
 his view/preference (nor exposes his for-next branch till the last
 minute, see now) many times it seems more as coin flipping.
 
 To me this attitude shows a failure of the community.  If I need to
 make every decision, then that doesn't scale.  People can ask
 questions a lot more easily than I can answer them.

No, you need to step in and be the benevolent dictator when people
have their thumbs up their asses and can't make up their minds,
otherwise things grind to a halt.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Or Gerlitz]

On Fri, Apr 3, 2015 at 1:31 AM, ira.weiny ira.we...@intel.com wrote:
 On Thu, Apr 02, 2015 at 05:32:53PM +0300, Or Gerlitz wrote:
 On Wed, Apr 1, 2015 at 12:33 AM, Hefty, Sean sean.he...@intel.com wrote:

 [snip]

 Your claim says more or less don't touch the good old
 include/rdma/ib_verbs.h from 2.6.12, just add new low-level drivers
 -- this is very close to claiming that it doesn't make sense to change
 anything in the low areas of the core networking stack or in
 netdevice.h over the years, just add new Ethernet drivers. This does
 not make any sense.

 I don't think the question is if we should change the core but how.

 Seans point is that the core seems to be in constant flux.  Furthermore, 
 Roland
 and others have found enough problems with the core changes in the past that
 they are _not_ comfortable applying them without serious review.

Ira, examples please for core changes that went in and later turned to
be problematic?! I refer to APIs and structural changes that turned to
be such (not or to less extent point bugs, which should be avoided
too, you know..)

 Many of the changes proposed here are completely new and require serious
 time to understand.
 Most people on this list have limited time and are unable to review every
 vendors hardware implementation.  What they do care about is how those
 changes
 affect the core and how those core changes then affect their hardware, other
 hardware they use, and the ULPs.  This becomes a huge amount of time.

You're mixing between vendor's driver code to core changes -- unable
to review every vendors hardware implementation -- is clear and we
didn't ask for that.

As for what's involved in merging core API changes - you made good
description of what's needed there --- but this is all about the
development and evolution of a core stack for domain X (networking,
block storage, virtualization, RDMA or you namde it). Such an argument
must not be used, since can kill X's stack development and the rdma
case, leave us with the 10y old 2.6.12 based verbs header file.

 To facilitate this we should be looking for ways to minimize and be very clear
 the ramifications of the core changes.  In addition, we need to identify where
 the core needs to be cleaned up such that future core changes are either 1)
 unnecessary or 2) easily reviewable because of their limited impact to other
 areas.

I am not sure to follow on the core cleanup proposal, but open for
suggestions / ideas, please elaborate on this little further.

 With all that said, I too must voice my concerns with Rolands lack of 
 activity.

 There have been some good discussions recently on re-architecting the device
 feature indicators which were spawned from my OPA MAD changes.

 Various alternatives have been submitted and discussed but Roland has not
 weighed in on which are acceptable.  This makes it difficult to determine what
 direction we should take.

Indeed. No maintainer voice makes it kind of impossible for
discussions to converge. What happens over the last years is that when
there's no easy consensus on matter Y, everyone stops breathing and
wait to see what happens on the rc1 night, b/c Roland doesn't spell
his view/preference (nor exposes his for-next branch till the last
minute, see now) many times it seems more as coin flipping.

 Also, recently I found out my repo for the 0-day build was no longer testing 
 my
 branches because Rolands for-next branch was too old.  I see today that Roland
 has updated to 4.0 rc now.  Thank you.


I added Sagi, Haggai and Shachar from Mellanox. They are behind few of
the major core changes that went in -- Protection/Signature (Sagi),
ODP (all), so if you find some concrete example on why/how these
changes were not architectured well enough, they will be happy to
listen and  respond.

BTW - the Signature verbs are now on their way to new use case, namely
offloading CPU %% used today for CRC and such calculations in
Web2/Hadoop  applications.

Haggai/Shachar are in-charge on the changes for name-spaces to support
containers on which Sean isn't responding for few months.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[ira.weiny]

On Thu, Apr 02, 2015 at 05:32:53PM +0300, Or Gerlitz wrote:
 On Wed, Apr 1, 2015 at 12:33 AM, Hefty, Sean sean.he...@intel.com wrote:

[snip]

 
 Your claim says more or less don't touch the good old
 include/rdma/ib_verbs.h from 2.6.12, just add new low-level drivers
 -- this is very close to claiming that it doesn't make sense to change
 anything in the low areas of the core networking stack or in
 netdevice.h over the years, just add new Ethernet drivers. This does
 not make any sense.

I don't think the question is if we should change the core but how.

Seans point is that the core seems to be in constant flux.  Furthermore, Roland
and others have found enough problems with the core changes in the past that
they are _not_ comfortable applying them without serious review.  Many of the
changes proposed here are completely new and require serious time to
understand.

Most people on this list have limited time and are unable to review every
vendors hardware implementation.  What they do care about is how those changes
affect the core and how those core changes then affect their hardware, other
hardware they use, and the ULPs.  This becomes a huge amount of time.

To facilitate this we should be looking for ways to minimize and be very clear
the ramifications of the core changes.  In addition, we need to identify where
the core needs to be cleaned up such that future core changes are either 1)
unnecessary or 2) easily reviewable because of their limited impact to other
areas.


With all that said, I too must voice my concerns with Rolands lack of activity.


There have been some good discussions recently on re-architecting the device
feature indicators which were spawned from my OPA MAD changes.

Various alternatives have been submitted and discussed but Roland has not
weighed in on which are acceptable.  This makes it difficult to determine what
direction we should take.

Also, recently I found out my repo for the 0-day build was no longer testing my
branches because Rolands for-next branch was too old.  I see today that Roland
has updated to 4.0 rc now.  Thank you.


Ira


 There are more and more new use cases for RDMA and indeed a nice
 challenge to frame them generally with modified/new verbs APIs and
 changes to the IB core, such as the patches to support name-spaces to
 make RDMA usable in containers which you (maintainer of the CM and
 RDMA-CM in the IB core) is ignoring for couple of months too
 (following Roland?).
 
 
  So examples please!
  Sure - this is from Somnath's latest patch series:
 
  Matan Barak (14):
IB/core: Add RoCE GID cache
IB/core: Add kref to IB devices
IB/core: Add RoCE GID population
IB/core: Add default GID for RoCE GID Cache
net/bonding: make DRV macros private
net: Add info for NETDEV_CHANGEUPPER event
IB/core: Add RoCE cache bonding support
IB/core: GID attribute should be returned from verbs API and cache API
IB/core: Report gid_type and gid_ndev through sysfs
IB/core: Support find sgid index using a filter function
IB/core: Modify ib_verbs and cma in order to use roce_gid_cache
IB/core: Add gid_type to path and rdma_id_private
IB/core: Add rdma_network_type to wc
IB/cma: Add configfs for rdma_cm
 
  Moni Shoua (13):
IB/mlx4: Remove gid table management for RoCE
IB/mlx4: Replace spin_lock with rw_semaphore
IB/mlx4: Lock with RCU instead of RTNL
net/mlx4: Postpone the registration of net_device
IB/mlx4: Advertise RoCE support in port capabilities
IB/mlx4: Implement ib_device callback - get_netdev
IB/mlx4: Implement ib_device callback - modify_gid
IB/mlx4: Configure device to work in RoCEv2
IB/mlx4: Translate cache gid index to real index
IB/core: Initialize UD header structure with IP and UDP headers
IB/mlx4: Enable send of RoCE QP1 packets with IP/UDP headers
IB/mlx4: Create and use another QP1 for RoCEv2
IB/cma: Join and leave multicast groups with IGMP
 
  That's a significant number of patches that modify the core rdma layer.
 
 This series indeed is a bit heavy as it brings three changes
 
 1. move the RoCE GID table management from LL drivers (ocrdma and
 mlx4) into the IB core
 2. support multiple GID types
 3. support RoCE V2
 
 #1 is terribly making sense, b/c RoCE GID addresses are derived
 through net events
 from IP addresses configured to the  buddy Ethernet net-device and uppers 
 (vlan,
 bond and such) so there's no point to have this logic replicated over
 and over in LL drivers.
 
 #2 and #3 follow the IBTA spec of RoCE V2
 
 It could be perfect maintainer comment to say: do it one-by-one, but
 anybody there?
 
 If you have concrete feedback on step #1 or anything else in the
 series, let them know.
 
  NFSoRDMA had 5 different ways to register memory.
 
 that's bad protocol implementation, so they are fixing it now. Has
 nothing to do with the IB core.
 
  I agree that Roland's response time is ridiculously slow.  But he does tend 
  to merge in 

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Or Gerlitz]

On Wed, Apr 1, 2015 at 12:33 AM, Hefty, Sean sean.he...@intel.com wrote:
 I must disagree. You made this claim back when we submitted the IB
 core patch which adds support for signature, protection etc offloads
 (commit 1b01d33560e7 IB/core: Introduce signature verbs API and the
 detailed replied you got were explaining that

 And I'll continue to make this claim because it is true.

 Very similar arguments would apply to the ODP submission.

 Yes - ODP will _have_ to change the core.  USNIC had to change the core, and 
 had changes rejected that made perfect sense conceptually.  This is part of 
 the problem!!!   If you disagree, then submit patches that don't touch the 
 core.

Sean,

ODP (On Demand Paging)

8ada2c1 IB/core: Add support for on demand paging regions
860f10a IB/core: Add flags for on demand paging support

is upstream for few releases already, and it changed the core indeed.
Memory Registration is sort of PITA for RDMA consumers and ODP is a
brilliant concept which down the road should be removing the hassle of
memory registration altogether (think on transparent lkey per process,
but days will tell).

As you pointed out during the USNIC review, it's sort of hack which is
not supported by any standard, unlike the other supported RDMA
technologies which are upstream: IB, RoCE and iWARP. But guess what,
the RDMA maintainer made no comments, and silently picked it up.

Your claim says more or less don't touch the good old
include/rdma/ib_verbs.h from 2.6.12, just add new low-level drivers
-- this is very close to claiming that it doesn't make sense to change
anything in the low areas of the core networking stack or in
netdevice.h over the years, just add new Ethernet drivers. This does
not make any sense.

There are more and more new use cases for RDMA and indeed a nice
challenge to frame them generally with modified/new verbs APIs and
changes to the IB core, such as the patches to support name-spaces to
make RDMA usable in containers which you (maintainer of the CM and
RDMA-CM in the IB core) is ignoring for couple of months too
(following Roland?).


 So examples please!
 Sure - this is from Somnath's latest patch series:

 Matan Barak (14):
   IB/core: Add RoCE GID cache
   IB/core: Add kref to IB devices
   IB/core: Add RoCE GID population
   IB/core: Add default GID for RoCE GID Cache
   net/bonding: make DRV macros private
   net: Add info for NETDEV_CHANGEUPPER event
   IB/core: Add RoCE cache bonding support
   IB/core: GID attribute should be returned from verbs API and cache API
   IB/core: Report gid_type and gid_ndev through sysfs
   IB/core: Support find sgid index using a filter function
   IB/core: Modify ib_verbs and cma in order to use roce_gid_cache
   IB/core: Add gid_type to path and rdma_id_private
   IB/core: Add rdma_network_type to wc
   IB/cma: Add configfs for rdma_cm

 Moni Shoua (13):
   IB/mlx4: Remove gid table management for RoCE
   IB/mlx4: Replace spin_lock with rw_semaphore
   IB/mlx4: Lock with RCU instead of RTNL
   net/mlx4: Postpone the registration of net_device
   IB/mlx4: Advertise RoCE support in port capabilities
   IB/mlx4: Implement ib_device callback - get_netdev
   IB/mlx4: Implement ib_device callback - modify_gid
   IB/mlx4: Configure device to work in RoCEv2
   IB/mlx4: Translate cache gid index to real index
   IB/core: Initialize UD header structure with IP and UDP headers
   IB/mlx4: Enable send of RoCE QP1 packets with IP/UDP headers
   IB/mlx4: Create and use another QP1 for RoCEv2
   IB/cma: Join and leave multicast groups with IGMP

 That's a significant number of patches that modify the core rdma layer.

This series indeed is a bit heavy as it brings three changes

1. move the RoCE GID table management from LL drivers (ocrdma and
mlx4) into the IB core
2. support multiple GID types
3. support RoCE V2

#1 is terribly making sense, b/c RoCE GID addresses are derived
through net events
from IP addresses configured to the  buddy Ethernet net-device and uppers (vlan,
bond and such) so there's no point to have this logic replicated over
and over in LL drivers.

#2 and #3 follow the IBTA spec of RoCE V2

It could be perfect maintainer comment to say: do it one-by-one, but
anybody there?

If you have concrete feedback on step #1 or anything else in the
series, let them know.

 NFSoRDMA had 5 different ways to register memory.

that's bad protocol implementation, so they are fixing it now. Has
nothing to do with the IB core.

 I agree that Roland's response time is ridiculously slow.  But he does tend 
 to merge in new drivers and updates that only touch a single vendor's driver 
 fairly quickly.  It's the thrashing on the core that sees significant delays.

Without ability to add the changed to the core, we can't make progress

Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Or Gerlitz]

On Tue, Mar 31, 2015 at 6:47 AM, Roland Dreier rol...@kernel.org wrote:
 Roland, I have to genuinely agree with Or, that your handling of
 patch integration is sub-par and really painful for anyone actually
 trying to get real work done here.

 If you simply don't have the time to devote to constantly reviewing
 patches as they come in, and doing so in a timely manner, please let
 someone who is actually interested and has the time to take over.

 It's a fair criticism, and certainly for at least the last year or so
 I have not had the time to do enough work as a maintainer.  I have
 hope that some of the things that have been keeping me busy are dying
 down and that I'll have more time to spend on handling the RDMA tree,
 but that's just talk until I actually get more done.

Roland, well, with few variations, this goes way beyond a year. I
would say more or less half of the time you're wearing the maintainer
hat (2005-now). The practice of updating your for-next branch to rc1
only few days/hours before the the kernel is out and the merge window
opens, is an attitude, not lack of resources and will not be solved by
whatever processes people suggest. You need to act differently.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Sagi Grimberg]

On 3/31/2015 6:47 AM, Roland Dreier wrote:

Roland, I have to genuinely agree with Or, that your handling of
patch integration is sub-par and really painful for anyone actually
trying to get real work done here.

If you simply don't have the time to devote to constantly reviewing
patches as they come in, and doing so in a timely manner, please let
someone who is actually interested and has the time to take over.


It's a fair criticism, and certainly for at least the last year or so
I have not had the time to do enough work as a maintainer.  I have
hope that some of the things that have been keeping me busy are dying
down and that I'll have more time to spend on handling the RDMA tree,
but that's just talk until I actually get more done.

I really would like to get more people involved in handling the flow
of patches but I'm not sure who has not only the interest and the time
but also the judgement and expertise to take over.  Certainly Or has
been a long time contributor who has done a lot of great things, but I
still worry about things like ABI stability and backwards
compatibility.

But I'm open to ideas.



We had a talk about a similar topic at LSFMM15. Linux-scsi subsystem is 
a large scale subsystem and also has the single maintainer with

limited time for upstream maintenance bottleneck.

Christoph created the scsi-queue tree to feed James in order to
accelerate the work process.

One thought was laying a set of rules that would allow a maintainer
to just apply patches:
- Obviously applies cleanly and does not produce compilation
errors/warning (patches that don't meet this will be removed)
- At least two Reviewed-by tags (one of them can be Acked-by/Tested-by)

One problem with that is that we need a christoph to poke people for
review since not a lot of people giving review.

Another thought was to allow multiple maintainers (my understanding is
the patchwork supports it). If we can find some split to allow different
maintainers to feed Roland this might work.

Thoughts?

Sagi.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Christoph Lameter]

Well this needs to be addressed yes but in order to have that done someone
needs to step forward do the proper work, maintain git trees, do the
review and show up for the conferences. Neither Roland nor Or was there at
the Infiniband conferences in Monterey this year(!) and this is the prime
venue for face to face conversation about the subsystem each year.

Just looked at the MAINTAINERS file: Surprise: We already have 3
maintainers for the IB subsystem:

INFINIBAND SUBSYSTEM
M:  Roland Dreier rol...@kernel.org
M:  Sean Hefty sean.he...@intel.com
M:  Hal Rosenstock hal.rosenst...@gmail.com
L:  linux-rdma@vger.kernel.org
W:  http://www.openfabrics.org/
Q:  http://patchwork.kernel.org/project/linux-rdma/list/
T:  git git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
S:  Supported
F:  Documentation/infiniband/
F:  drivers/infiniband/
F:  include/uapi/linux/if_infiniband.h

Sean and Hal showed up for the conference. Sean is active mostly in
focusing on userspace stuff. Both could become more involved in the kernel
ib tree and the review process? Hal is employed by Mellanox but is not
participating in these patch related discussions? Can Mellanox give Hal
more time for his role as the kernel ib subsystem maintainer? Maybe you
could get that resolved at Mellanox? You already have one of your own as
a maintainer of the IB subsystem.


--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Hal Rosenstock]

On 3/31/2015 8:49 AM, Christoph Lameter wrote:
 Well this needs to be addressed yes but in order to have that done someone
 needs to step forward do the proper work, maintain git trees, do the
 review and show up for the conferences. Neither Roland nor Or was there at
 the Infiniband conferences in Monterey this year(!) and this is the prime
 venue for face to face conversation about the subsystem each year.
 
 Just looked at the MAINTAINERS file: Surprise: We already have 3
 maintainers for the IB subsystem:
 
 INFINIBAND SUBSYSTEM
 M:  Roland Dreier rol...@kernel.org
 M:  Sean Hefty sean.he...@intel.com
 M:  Hal Rosenstock hal.rosenst...@gmail.com
 L:  linux-rdma@vger.kernel.org
 W:  http://www.openfabrics.org/
 Q:  http://patchwork.kernel.org/project/linux-rdma/list/
 T:  git 
 git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
 S:  Supported
 F:  Documentation/infiniband/
 F:  drivers/infiniband/
 F:  include/uapi/linux/if_infiniband.h
 
 Sean and Hal showed up for the conference. Sean is active mostly in
 focusing on userspace stuff. Both could become more involved in the kernel
 ib tree and the review process? Hal is employed by Mellanox but is not
 participating in these patch related discussions? Can Mellanox give Hal
 more time for his role as the kernel ib subsystem maintainer? Maybe you
 could get that resolved at Mellanox? You already have one of your own as
 a maintainer of the IB subsystem.

My involvement is limited to IB management related aspects in the kernel.

-- Hal

--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[David Miller]

From: Or Gerlitz gerlitz...@gmail.com
Date: Tue, 31 Mar 2015 14:22:50 +0300

 On Tue, Mar 31, 2015 at 6:47 AM, Roland Dreier rol...@kernel.org wrote:
 Roland, I have to genuinely agree with Or, that your handling of
 patch integration is sub-par and really painful for anyone actually
 trying to get real work done here.

 If you simply don't have the time to devote to constantly reviewing
 patches as they come in, and doing so in a timely manner, please let
 someone who is actually interested and has the time to take over.

 It's a fair criticism, and certainly for at least the last year or so
 I have not had the time to do enough work as a maintainer.  I have
 hope that some of the things that have been keeping me busy are dying
 down and that I'll have more time to spend on handling the RDMA tree,
 but that's just talk until I actually get more done.
 
 Roland, well, with few variations, this goes way beyond a year. I
 would say more or less half of the time you're wearing the maintainer
 hat (2005-now). The practice of updating your for-next branch to rc1
 only few days/hours before the the kernel is out and the merge window
 opens, is an attitude, not lack of resources and will not be solved by
 whatever processes people suggest. You need to act differently.

Unfortunately, and no direct offense intend to you personally Roland,
but I agree with Or here.

If a person really cares about a subsystem they are marked at the
maintainer for, they usually _make_ the time necessary to apply
patches and attend to maintainership in a reasonable manner.

If this once every merge window behavior was limited to one release
cycle, I'd give the benefit of the doubt, but this has been going on
for a very long time.

You cannot on the one hand say I care about this subsystem and the
long term maintainership and ABI stability of it yet on the other
hand not be willing to put forth even the _MOST MINIMAL_ amount of
effort and time required to steadily review and apply patches over a
period of several years.

It doesn't take a lot of time to do this work, especially if you use
the correct tools.  I can review and apply 100 patches a day, even
when I'm on vacation.  I'm an extreme example, but what you're doing
right now Roland is not acceptable and is not in agreement with your
claims about how much you care about this subsystem.

If you processed the incoming patch queue even _once_ a week, we
wouldn't even be having this conversation.  But you haven't even been
doing that.

I get sick to my stomache when a patch gets to 3 days in my patch
queue, that's already too long.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Christoph Lameter]

On Tue, 31 Mar 2015, Hal Rosenstock wrote:

  Sean and Hal showed up for the conference. Sean is active mostly in
  focusing on userspace stuff. Both could become more involved in the kernel
  ib tree and the review process? Hal is employed by Mellanox but is not
  participating in these patch related discussions? Can Mellanox give Hal
  more time for his role as the kernel ib subsystem maintainer? Maybe you
  could get that resolved at Mellanox? You already have one of your own as
  a maintainer of the IB subsystem.

 My involvement is limited to IB management related aspects in the kernel.

Need to update the entry then I think.

--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[David Miller]

From: Christoph Lameter c...@linux.com
Date: Tue, 31 Mar 2015 07:49:38 -0500 (CDT)

 Well this needs to be addressed yes but in order to have that done someone
 needs to step forward do the proper work, maintain git trees, do the
 review and show up for the conferences. Neither Roland nor Or was there at
 the Infiniband conferences in Monterey this year(!) and this is the prime
 venue for face to face conversation about the subsystem each year.

I don't go to IETF meetings, ever, yet I am rather sure that nobody
uses that to question my ability to be the networking maintainer.

I've gone several years at times without meeting other networking
developers as well, and that also I am pretty sure did not harm my
stature as the networking maintainer.

So I absolutely disagree that these two acts are requirements for
someone whose job is to steadily and reasonably review and apply
patches for a subsystem.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Christoph Lameter]

On Tue, 31 Mar 2015, David Miller wrote:

  Well this needs to be addressed yes but in order to have that done someone
  needs to step forward do the proper work, maintain git trees, do the
  review and show up for the conferences. Neither Roland nor Or was there at
  the Infiniband conferences in Monterey this year(!) and this is the prime
  venue for face to face conversation about the subsystem each year.

 I don't go to IETF meetings, ever, yet I am rather sure that nobody
 uses that to question my ability to be the networking maintainer.

This isnt a standards body. Openfabrics is the organization dedicated to
the development of the infiniband stack.

--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Jason Gunthorpe]

On Tue, Mar 31, 2015 at 12:13:58PM +0300, Sagi Grimberg wrote:

 We had a talk about a similar topic at LSFMM15. Linux-scsi subsystem
 is a large scale subsystem and also has the single maintainer with
 limited time for upstream maintenance bottleneck.
 
 Christoph created the scsi-queue tree to feed James in order to
 accelerate the work process.

[..]

 One problem with that is that we need a christoph to poke people for
 review since not a lot of people giving review.

I have tried for a few years to get enough interested/qualified people
together to do this kind of system, but it just hasn't happened.

It feels like we are stuck in a loop: People and companies *do not*
want to work on drivers/infiniband because too often patches just die.
Asking people to work on it, and companies to fund work, gets met with
the above.

I think there is a broad agreement we need to change the system
here. So, lets hear from people and companies: put your name forward,
consistently provide time to do serious review work on all patches.

Jason
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Hefty, Sean]

 It doesn't take a lot of time to do this work, especially if you use
 the correct tools.  I can review and apply 100 patches a day, even
 when I'm on vacation.  I'm an extreme example, but what you're doing
 right now Roland is not acceptable and is not in agreement with your
 claims about how much you care about this subsystem.

I honestly think part of the issue here is general approach being taken by the 
rdma stack, which is to expose every hardware specific component that a vendor 
might define through the interfaces up to the consumers.  This results in 
unwieldy interfaces that are under constant churn, with no clear direction.  If 
most submissions to the rdma stack were contained the lower-level drivers, I 
don't know that we would have the issues that we do.  But a significant 
percentage of rdma patches modify the rdma core software layer, which threaten 
the stability of the entire stack.

- Sean
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Or Gerlitz]

On Tue, Mar 31, 2015 at 8:27 PM, Hefty, Sean sean.he...@intel.com wrote:


 I honestly think part of the issue here is general approach being taken by 
 the rdma stack, which is to expose every hardware specific component that a 
 vendor might define through the interfaces up to the consumers.

Sean,

I must disagree. You made this claim back when we submitted the IB
core patch which adds support for signature, protection etc offloads
(commit 1b01d33560e7 IB/core: Introduce signature verbs API and the
detailed replied you got were explaining that

1. this allows to offload SCSI T10 signature for RDMA block storage
protocols such as SRP and iSER
2. SCSI, SRP and iSER are all industry standards
3. T10 offload is done also by competing technologies such as Fibre-Channel
4. nothing, but exactly nothing in the verbs API is tied to specific
HCA implementation
5. etc

Very similar arguments would apply to the ODP submission.

So examples please!

Or.

This results in unwieldy interfaces that are under constant churn,
with no clear direction.  If most submissions to the rdma stack were
contained the lower-level drivers, I don't know that we would have the
issues that we do.  But a significant percentage of rdma patches
modify the rdma core software layer, which threaten the stability of
the entire stack.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Hefty, Sean]

 I must disagree. You made this claim back when we submitted the IB
 core patch which adds support for signature, protection etc offloads
 (commit 1b01d33560e7 IB/core: Introduce signature verbs API and the
 detailed replied you got were explaining that

And I'll continue to make this claim because it is true.

 Very similar arguments would apply to the ODP submission.

Yes - ODP will _have_ to change the core.  USNIC had to change the core, and 
had changes rejected that made perfect sense conceptually.  This is part of the 
problem!!!   If you disagree, then submit patches that don't touch the core.

 So examples please!

Sure - this is from Somnath's latest patch series:

Matan Barak (14):
  IB/core: Add RoCE GID cache
  IB/core: Add kref to IB devices
  IB/core: Add RoCE GID population
  IB/core: Add default GID for RoCE GID Cache
  net/bonding: make DRV macros private
  net: Add info for NETDEV_CHANGEUPPER event
  IB/core: Add RoCE cache bonding support
  IB/core: GID attribute should be returned from verbs API and cache API
  IB/core: Report gid_type and gid_ndev through sysfs
  IB/core: Support find sgid index using a filter function
  IB/core: Modify ib_verbs and cma in order to use roce_gid_cache
  IB/core: Add gid_type to path and rdma_id_private
  IB/core: Add rdma_network_type to wc
  IB/cma: Add configfs for rdma_cm

Moni Shoua (13):
  IB/mlx4: Remove gid table management for RoCE
  IB/mlx4: Replace spin_lock with rw_semaphore
  IB/mlx4: Lock with RCU instead of RTNL
  net/mlx4: Postpone the registration of net_device
  IB/mlx4: Advertise RoCE support in port capabilities
  IB/mlx4: Implement ib_device callback - get_netdev
  IB/mlx4: Implement ib_device callback - modify_gid
  IB/mlx4: Configure device to work in RoCEv2
  IB/mlx4: Translate cache gid index to real index
  IB/core: Initialize UD header structure with IP and UDP headers
  IB/mlx4: Enable send of RoCE QP1 packets with IP/UDP headers
  IB/mlx4: Create and use another QP1 for RoCEv2
  IB/cma: Join and leave multicast groups with IGMP

That's a significant number of patches that modify the core rdma layer.  
NFSoRDMA had 5 different ways to register memory.

I agree that Roland's response time is ridiculously slow.  But he does tend to 
merge in new drivers and updates that only touch a single vendor's driver 
fairly quickly.  It's the thrashing on the core that sees significant delays.

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[David Miller]

From: Or Gerlitz gerlitz...@gmail.com
Date: Mon, 30 Mar 2015 19:17:01 +0300

 On Sun, Mar 29, 2015 at 4:51 PM, Or Gerlitz ogerl...@mellanox.com wrote:
 Under the existing implementation for virtual GIDs, if the SM is not
 reachable or incurs a delayed response, or if the VF is probed into a
 VM before their GUID is registered with the SM, there exists a window
 in time in which the VF sees an incorrect GID, i.e., not the GID that
 was intended by the admin. This results in exposing a temporal identity
 to the VF.
 
 Hi Roland, so your for-next branch is again way behind, still on 3.19
 and while 4.0 is soon @ rc6, we couldn't even rebase this series on
 it. It's really hard where your tree is really active once every nine
 weeks or so, e.g only few days before/after rc1's. I'm not sure what
 you expect us to do, kernel development simply needs not be like this.
 
 April 3rd-12th is holiday here, and we would like to really really
 know early this week what you intend to pull for 4.1 out of the
 pending things in linux-rdma.

Roland, I have to genuinely agree with Or, that your handling of
patch integration is sub-par and really painful for anyone actually
trying to get real work done here.

If you simply don't have the time to devote to constantly reviewing
patches as they come in, and doing so in a timely manner, please let
someone who is actually interested and has the time to take over.

Only integrating peoples work right before the merge window, and then
disappearing for a long time really isn't acceptable.

Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Roland Dreier]

 Roland, I have to genuinely agree with Or, that your handling of
 patch integration is sub-par and really painful for anyone actually
 trying to get real work done here.

 If you simply don't have the time to devote to constantly reviewing
 patches as they come in, and doing so in a timely manner, please let
 someone who is actually interested and has the time to take over.

It's a fair criticism, and certainly for at least the last year or so
I have not had the time to do enough work as a maintainer.  I have
hope that some of the things that have been keeping me busy are dying
down and that I'll have more time to spend on handling the RDMA tree,
but that's just talk until I actually get more done.

I really would like to get more people involved in handling the flow
of patches but I'm not sure who has not only the interest and the time
but also the judgement and expertise to take over.  Certainly Or has
been a long time contributor who has done a lot of great things, but I
still worry about things like ABI stability and backwards
compatibility.

But I'm open to ideas.

 - R.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] mlx4 changes in virtual GID management

[Or Gerlitz]

On Sun, Mar 29, 2015 at 4:51 PM, Or Gerlitz ogerl...@mellanox.com wrote:
 Under the existing implementation for virtual GIDs, if the SM is not
 reachable or incurs a delayed response, or if the VF is probed into a
 VM before their GUID is registered with the SM, there exists a window
 in time in which the VF sees an incorrect GID, i.e., not the GID that
 was intended by the admin. This results in exposing a temporal identity
 to the VF.

Hi Roland, so your for-next branch is again way behind, still on 3.19
and while 4.0 is soon @ rc6, we couldn't even rebase this series on
it. It's really hard where your tree is really active once every nine
weeks or so, e.g only few days before/after rc1's. I'm not sure what
you expect us to do, kernel development simply needs not be like this.

April 3rd-12th is holiday here, and we would like to really really
know early this week what you intend to pull for 4.1 out of the
pending things in linux-rdma.

Or.


 Moreover, a subsequent change in the alias GID causes a spec-incompliant
 change to the VF identity. Some guest operating systems, such as Windows,
 cannot tolerate such changes.

 This series solves above problem by exposing the admin desired value instead
 of the value that was approved by the SM. As long as the SM doesn't approve
 the GID, the VF would see its link as down.

 In addition, we request GIDs from the SM on demand, i.e., when a VF actually
 needs them, and release them when the GIDs are no longer in use. In cloud
 environments, this is useful for GID migrations, in which a GID is assigned to
 a VF on the destination HCA, while the VF on the source HCA is shut down (but
 the GID was not administratively released).

 For reasons of compatibility, an explicit admin request to set/change a GUID
 entry is done immediately, regardless of whether the VF is active or not. This
 allows administrators to change the GUID without the need to unbind/bind the 
 VF.

 In addition, the existing implementation doesn't support a persistency
 mechanism to retry a GUID request when the SM has rejected it for any reason.
 The PF driver shall keep trying to acquire the specified GUID indefinitely by
 utilizing an exponential back off scheme, this should be managed per GUID and
 be aligned with other incoming admin requests.

 This ability needed especially for the on-demand GUID feature. In this case, 
 we
 must manage the GUID's status per entry and handle cases that some entries are
 temporarily rejected.

 The first patch adds the persistency support and is pre-requisites for the
 series.  Further patches make the change to use the admin VF behavior as
 described above.

 Finally, the default mode is changed to be HOST assigned instead of SM
 assigned. This is the expected operational mode, because it doesn't depend on
 SM availability as described above.

 Yishai and Or.

 Yishai Hadas (9):
   IB/mlx4: Alias GUID adding persistency support
   net/mlx4_core: Manage alias GUID per VF
   net/mlx4_core: Set initial admin GUIDs for VFs
   IB/mlx4: Manage admin alias GUID upon admin request
   IB/mlx4: Change init flow to request alias GUIDs for active VFs
   IB/mlx4: Request alias GUID on demand
   net/mlx4_core: Raise slave shutdown event upon FLR
   net/mlx4_core: Return the admin alias GUID upon host view request
   IB/mlx4: Change alias guids default to be host assigned

  drivers/infiniband/hw/mlx4/alias_GUID.c   |  468 
 +
  drivers/infiniband/hw/mlx4/main.c |   26 ++-
  drivers/infiniband/hw/mlx4/mlx4_ib.h  |   14 +-
  drivers/infiniband/hw/mlx4/sysfs.c|   44 +--
  drivers/net/ethernet/mellanox/mlx4/cmd.c  |   42 ++-
  drivers/net/ethernet/mellanox/mlx4/eq.c   |2 +
  drivers/net/ethernet/mellanox/mlx4/main.c |   39 +++
  drivers/net/ethernet/mellanox/mlx4/mlx4.h |1 +
  include/linux/mlx4/device.h   |4 +
  9 files changed, 459 insertions(+), 181 deletions(-)

 --
 To unsubscribe from this list: send the line unsubscribe linux-rdma in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for-next 0/9] mlx4 changes in virtual GID management

[Or Gerlitz]

Under the existing implementation for virtual GIDs, if the SM is not 
reachable or incurs a delayed response, or if the VF is probed into a
VM before their GUID is registered with the SM, there exists a window 
in time in which the VF sees an incorrect GID, i.e., not the GID that 
was intended by the admin. This results in exposing a temporal identity 
to the VF.

Moreover, a subsequent change in the alias GID causes a spec-incompliant
change to the VF identity. Some guest operating systems, such as Windows,
cannot tolerate such changes.

This series solves above problem by exposing the admin desired value instead 
of the value that was approved by the SM. As long as the SM doesn't approve 
the GID, the VF would see its link as down.

In addition, we request GIDs from the SM on demand, i.e., when a VF actually
needs them, and release them when the GIDs are no longer in use. In cloud
environments, this is useful for GID migrations, in which a GID is assigned to
a VF on the destination HCA, while the VF on the source HCA is shut down (but
the GID was not administratively released).

For reasons of compatibility, an explicit admin request to set/change a GUID
entry is done immediately, regardless of whether the VF is active or not. This
allows administrators to change the GUID without the need to unbind/bind the VF.

In addition, the existing implementation doesn't support a persistency
mechanism to retry a GUID request when the SM has rejected it for any reason.
The PF driver shall keep trying to acquire the specified GUID indefinitely by
utilizing an exponential back off scheme, this should be managed per GUID and
be aligned with other incoming admin requests.

This ability needed especially for the on-demand GUID feature. In this case, we
must manage the GUID's status per entry and handle cases that some entries are
temporarily rejected.

The first patch adds the persistency support and is pre-requisites for the
series.  Further patches make the change to use the admin VF behavior as
described above.

Finally, the default mode is changed to be HOST assigned instead of SM
assigned. This is the expected operational mode, because it doesn't depend on
SM availability as described above.

Yishai and Or.

Yishai Hadas (9):
  IB/mlx4: Alias GUID adding persistency support
  net/mlx4_core: Manage alias GUID per VF
  net/mlx4_core: Set initial admin GUIDs for VFs
  IB/mlx4: Manage admin alias GUID upon admin request
  IB/mlx4: Change init flow to request alias GUIDs for active VFs
  IB/mlx4: Request alias GUID on demand
  net/mlx4_core: Raise slave shutdown event upon FLR
  net/mlx4_core: Return the admin alias GUID upon host view request
  IB/mlx4: Change alias guids default to be host assigned

 drivers/infiniband/hw/mlx4/alias_GUID.c   |  468 +
 drivers/infiniband/hw/mlx4/main.c |   26 ++-
 drivers/infiniband/hw/mlx4/mlx4_ib.h  |   14 +-
 drivers/infiniband/hw/mlx4/sysfs.c|   44 +--
 drivers/net/ethernet/mellanox/mlx4/cmd.c  |   42 ++-
 drivers/net/ethernet/mellanox/mlx4/eq.c   |2 +
 drivers/net/ethernet/mellanox/mlx4/main.c |   39 +++
 drivers/net/ethernet/mellanox/mlx4/mlx4.h |1 +
 include/linux/mlx4/device.h   |4 +
 9 files changed, 459 insertions(+), 181 deletions(-)

--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html