Re: device attr cleanup (was: Handle mlx4 max_sge_rd correctly)

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

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

On 12/10/2015 11:10 AM, Steve Wise wrote:
> 
> 
>> -----Original Message-----
>> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-owner@vger.kernel.org] On Behalf Of Chuck Lever
>> Sent: Thursday, December 10, 2015 10:08 AM
>> To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: ira.weiny; Christoph Hellwig; Jason Gunthorpe; Or Gerlitz; Steve Wise; Or Gerlitz; Sagi Grimberg; Doug Ledford
>> Subject: Re: device attr cleanup (was: Handle mlx4 max_sge_rd correctly)
>>
>>
>>> On Dec 10, 2015, at 3:27 AM, Sagi Grimberg <sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
>>>
>>>
>>>
>>>> Doug this is going to conflict with the rdmavt work.  So if you take this could
>>>> you respond on the list.
>>>
>>> It will also conflict with the iser remote invalidate series.
>>>
>>> Doug it would help if you share your plans so people can rebase
>>> accordingly.
>>
>> I would be remiss not to mention that it probably also
>> conflicts with the NFS server bi-directional RPC/RDMA
>> series.
>>
>> Invasive IB core changes like this clean up are especially
>> burdensome for me because NFS/RDMA changes do not normally
>> go through Doug's tree, so it takes extra co-ordination.
>>
>> Here is a modest proposal. An obvious way to split the
>> device attr cleanup might go like this:
>>
>> a. first patch: add new fields to ib_device
>> b. then one patch for each provider to populate these fields
>> c. then one patch for each kernel ULP to use the new fields
>> d. then one patch for each provider to remove ->query_attr
>> e. last patch: remove ib_device_attr from the IB core
>>
>> That way each provider and ULP maintainer can review and
>> ack the portion of the changes that he or she is responsible
>> for, and it should help make it much easier to merge with
>> conflicting changes.
>>
>> Splitting it across more than one kernel release would be
>> helpful too, IMO. a. and b. can go into 4.5, c. into 4.6,
>> and d. and e. can go in any time after that.
>>
>> This adds more "process" but given the long chain of core
>> changes now in plan, we should acknowledge how disruptive
>> they will be, and come up with ways to make it possible to
>> get other work done while the core maintenance work
>> progresses.
>>
>>
> 
> The approach sounds reasonable to me.

This isn't a bad plan if we go that way.

Now here's where I get to speak my mind on things (since people have
been asking).


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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]