[ewg] [PATCH v4] IB Core: RAW ETH support

Steve Wise swise at opengridcomputing.com
Wed Jun 16 11:35:07 PDT 2010


Jason Gunthorpe wrote:
> On Wed, Jun 16, 2010 at 12:12:06PM -0500, Steve Wise wrote:
>
>   
>>>> Granted our dev process may not be documented, but I always assumed 
>>>> the general idea was to get changes accepted upstream, then pull into 
>>>> ofed. OFED is just a mechanism to make top-of-tree linux work on 
>>>> distro kernels. There are some exceptions, but this stuff shouldn't 
>>>> be an exception.
>>>>         
>
>   
>>> That is what many people wish for, me included, but it is not at all
>>> what generally happens :(
>>>
>>> In my observation the typical flow is:
>>>  - A patch is written, it may or may not be sent to the list
>>>  - 'business drivers' get it slammed into OFED right away
>>>  - A patch is finally sent for proper review
>>>  - It is not merged, there are comments..
>>>  - Interest in doing anything is lost because it is already in
>>>    OFED and that is all that matters, right?
>>>  - People complain.
>>>
>>> For instance, the iWarp thingy we were just discussing fits this
>>> process rather well.
>>>       
>
>   
>> You're wrong.  I started that iWARP change in 2007 on LKLM.  I proposed  
>> a few ideas and show the pros/cons of each.  And it was NAKed 100% by  
>> mister miller.    It was then included in OFED as a last resort only  
>> because I couldn't get any help with trying to add this upstream in any  
>> form.  I even spent a few weeks developing a way to administor "iwarp  
>> only" ipaddresses, but Roland didn't like that scheme for various  
>> reasons.  So please don't mention that particular patch as a "bad  
>> process" unless you want to argue with me some more about it.
>>     
>
> Uhm, what you just described does fit my process outline:
>
>  #1 - Patch written, sent to LKML. Check.
>  #3 - Patch sent for proper review - in 2007. Check.
>  #4 - Not merged. NAK by DM. Check.
>  #2 - 'business drivers' force it into OFED - 'last resort' ie, iWarp
>       cards can't be used without some fix. Check.
>  #5 - Interest is lost. Yep, this was done in 2007, and it was idle
>       till now. Check.
>  #6 - People Complain. Hmm. Yep. Check.
>
>   

Note the ordering is different.  IE I tried very hard to get the "right" 
solution designed and agreed-upon upstream.  But failed.  That's my 
bad.    I did, however help with the iWARP core code including neighbour 
update net events which did go in upstream before ofed.

> Don't think I'm being critical toward only you, or singling out that
> little iWarp patch. But it really isn't special, or different, or an
> exception. Pick nearly any patch in OFED and someone will rush to its
> defense with a 'we tried to follow the process and it failed, so we
> did it anyway' argument.
>
> I also didn't say this is the only way that RDMA development goes,
> lots and lots of stuff goes into mainline first, from everyone.
>
> Jason
>   


OFED maintainers should be more rigid, perhaps, with requiring that 
changes be accepted upstream first.  One observation is that there is no 
"OFED RDMA maintainer", aka a Roland Dreier, for the OFED code.  So each 
driver maintainer pretty much has free reign to do the right thing or 
the wrong thing...


Steve.





More information about the ewg mailing list