Re: Prepared RDMA Tree for 4.7

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3681 bytes --]

On Sat, May 14, 2016 at 09:09:54AM -0400, Doug Ledford wrote:
> On 05/14/2016 12:33 AM, Leon Romanovsky wrote:
> > On Fri, May 13, 2016 at 12:31:55PM -0400, Doug Ledford wrote:
> > 
> > <snip>
> > 
> > I had an intent to help you,
> 
> That's fine.  As I pointed out in my email, I need to know what I'm
> sending to Linus.
> 
> > So can you please share with us your plans on how-to address the
> > general lack of "communication, transparency and coordination",
> > which is definitely happen here?
> 
> I could always just artificially limit each release to no more than 100
> patches or something like that.  Then I would have more time per patch
> to be communicative.  But that wouldn't make people happy, it would take
> months and years to get things done.

Most of the patches are fixes and a lot of them one line only. They can
be acknowledged and applied in more timely manner. This will definitely
remove the tension.

For example, I have a build warning fix for hfi1 driver, but I prefer
don't send it till I see their fixes are applied.

> 
> But you guys are only partially mad at me.  I'm not the sole
> person/group holding you up from getting your way.

You are the one who makes decision, and not other persons/groups.

> For example the LSO
> patches aren't in, and that because they are an API extension that not
> everyone understands what LSO in that context means.  The patch set
> needs more explanation so that others can actually say if it's generic
> enough to meet their needs.

I agree with you and this is why we are posting it on the ML and adjust
the patches to answer on the feedback.

I don't see it is a blocker, but as a part of open discussion to adjust
patches to meet upstream criteria.

> You guys have a ton of features you want to
> get into the kernel, each one being a different sort of hardware
> offload, and while you may have worked with customers to do the initial
> creation, you didn't work with the community on describing them or
> anything else, and you bring them here fully done to your satisfaction,
> and it takes other people time to wrap their head around what they are,
> whether or not they might be usable in their own hardware, and then to
> decide if the design as presented would work for them if they did decide
> to implement it.  Without their input, I'm left in a rather untenable
> position.  And frankly, I'm rather sick of being in that position.

What is wrong with SELinux patches?

> 
> I'm quickly coming to agree with the results of the collaboration summit
> in that if a patch set implements a new feature in the form of a user
> visible API change (aka, a new flag to create_qp or a change to user
> visible work completions, that sort of thing), then patches will need
> buy in from other vendors before I'll accept them (where buy in means
> they've read it, they've understood it, and they've publicly given their
> Acked-by: line....silence does not equal buy in!).

There are three issues with this request:
1. It is not silence, but readiness to merge, since all feedback is
answered and everything is understandable. LSO patches are great
example for it, if the people don't understand they will ask and will
request to adjust patches accordingly.
2. It will limit ability to move IB stack further and will eliminate
fair competitive market.
3. According to IBTA [1], there are almost no HW vendors in this field.

[1] http://www.infinibandta.org/content/pages.php?pg=products_overview

> 
> -- 
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>               GPG KeyID: 0E572FDD
> 
> 



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]