> -----Original Message----- > From: linux-rdma-ow...@vger.kernel.org > [mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Chuck Lever > Sent: Thursday, December 10, 2015 10:08 AM > To: linux-rdma@vger.kernel.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 <sa...@dev.mellanox.co.il> 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. 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
