On 2/2/07, Chuck Lever <[email protected]> wrote:
> Roland Dreier wrote:
> > > They are mostly from Chuck Level and make preparating for IPv6 support
> > > in the NFS server.
> > > They are *not* for 2.6.20, but should be ok for .21.
> >
> > Out of curiousity, does this patch series reduce the delta between the
> > NFS/RDMA tree and mainline Linux? In other words does this bring
> > NFS/RDMA closer to merging?
>
> Hi Roland-
>
> The client side support for an RPC/RDMA module is almost completely
> integrated into mainline. There is still a minimal set of patches
> required to support alternate transports in loadable kernel modules
> which Trond has indicated he will integrate when the RPC/RDMA transport
> is ready to be integrated.
Hi Chuck,
I must be missing something because I don't see _any_ trace of the
core RPC over RDMA support (xprtrdma et al), your RPC Transport
Switch, or any of the other supporting changes in mainline. Could
you, or others, please clarify the plan for merging RPC/RDMA?
> At this time I'm not aware of a plan to integrate server-side support
> for NFS/RDMA. Perhaps the NetApp RDMA developers could respond.
Do you mean the NFS/RDMA server code from Tom Tucker of Open Grid
Computing? Why wouldn't this code be included?
please advise, thanks.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On 4/13/07, Trond Myklebust <[email protected]> wrote:
> On Fri, 2007-04-13 at 16:47 -0400, Mike Snitzer wrote:
> > I must be missing something because I don't see _any_ trace of the
> > core RPC over RDMA support (xprtrdma et al), your RPC Transport
> > Switch, or any of the other supporting changes in mainline. Could
> > you, or others, please clarify the plan for merging RPC/RDMA?
>
> That would be a question for the actual RPC/RDMA developers (i.e. James
> Lentini and Tom Talpey). They haven't submitted any code for review yet.
The reason I asked is there seems to be a catch-22 going on here if
(as Chuck indicated) the NetApp engineers are waiting for the
remaining rpc transport switch patches to be merged. My naive
understanding is that those remaining transport switch patches aren't
_really_ needed without the RPC/RDMA patches.
Essentially I'm echoing Or Gerlitz's post to openib-general back in December:
http://lists.openfabrics.org/pipermail/general/2006-December/029721.html
If so, it begs the question: why the hold up from the NetApp
engineers? In the hopes of getting some insight I've cc'd James
Lentini and Tom Talpey.
I'm assuming that all of you obviously want your code merged mainline.
The thing that is puzzling is the non-traditional release management
of this RPC/RDMA and NFS/RDMA code. Aside from the periodic
announcements of the tarball updates to the sf.net nfs-rdma project;
I've not found any posting/discussion of associated patches to the
various mailing lists (nfs, nfsv4, ofa's general, lkml, etc).
I'm interested in understanding why the reluctance to push for a merge
now (let alone some months ago) given the various successes that have
been seen with the NFS/RDMA effort (Sandia, SC '06, as Chuck noted:
good performance at various test sites). If the code is holding up
well why the delay in review and merging? And rather than wait for
the remaining transport switch patches; why not look to merge all of
NFS/RDMA (client) work at the same time?
regards,
Mike
On Sat, 14 Apr 2007, Mike Snitzer wrote:
> On 4/13/07, Trond Myklebust <[email protected]> wrote:
> > On Fri, 2007-04-13 at 16:47 -0400, Mike Snitzer wrote:
> > > I must be missing something because I don't see _any_ trace of the
> > > core RPC over RDMA support (xprtrdma et al), your RPC Transport
> > > Switch, or any of the other supporting changes in mainline. Could
> > > you, or others, please clarify the plan for merging RPC/RDMA?
> >
> > That would be a question for the actual RPC/RDMA developers (i.e. James
> > Lentini and Tom Talpey). They haven't submitted any code for review yet.
>
> The reason I asked is there seems to be a catch-22 going on here if
> (as Chuck indicated) the NetApp engineers are waiting for the
> remaining rpc transport switch patches to be merged. My naive
> understanding is that those remaining transport switch patches aren't
> _really_ needed without the RPC/RDMA patches.
>
> Essentially I'm echoing Or Gerlitz's post to openib-general back in December:
> http://lists.openfabrics.org/pipermail/general/2006-December/029721.html
>
> If so, it begs the question: why the hold up from the NetApp
> engineers? In the hopes of getting some insight I've cc'd James
> Lentini and Tom Talpey.
>
> I'm assuming that all of you obviously want your code merged mainline.
> The thing that is puzzling is the non-traditional release management
> of this RPC/RDMA and NFS/RDMA code. Aside from the periodic
> announcements of the tarball updates to the sf.net nfs-rdma project;
> I've not found any posting/discussion of associated patches to the
> various mailing lists (nfs, nfsv4, ofa's general, lkml, etc).
>
> I'm interested in understanding why the reluctance to push for a merge
> now (let alone some months ago) given the various successes that have
> been seen with the NFS/RDMA effort (Sandia, SC '06, as Chuck noted:
> good performance at various test sites). If the code is holding up
> well why the delay in review and merging? And rather than wait for
> the remaining transport switch patches; why not look to merge all of
> NFS/RDMA (client) work at the same time?
There is no reluctance to submit the NFS-RDMA code for review. There
have been several upstream changes to the NFS server recently. We
(NetApp and Tom Tucker at OGC) are working on a new patchset for
NFS-RDMA that is compatible with these changes. We are testing the
code now.
We will post the patches for review when we finish updating them.
On 4/16/07, James Lentini <[email protected]> wrote:
>
>
> On Sat, 14 Apr 2007, Mike Snitzer wrote:
>
> > I'm interested in understanding why the reluctance to push for a merge
> > now (let alone some months ago) given the various successes that have
> > been seen with the NFS/RDMA effort (Sandia, SC '06, as Chuck noted:
> > good performance at various test sites). If the code is holding up
> > well why the delay in review and merging? And rather than wait for
> > the remaining transport switch patches; why not look to merge all of
> > NFS/RDMA (client) work at the same time?
>
> There is no reluctance to submit the NFS-RDMA code for review. There
> have been several upstream changes to the NFS server recently. We
> (NetApp and Tom Tucker at OGC) are working on a new patchset for
> NFS-RDMA that is compatible with these changes. We are testing the
> code now.
>
> We will post the patches for review when we finish updating them.
Thanks for the clarification. It was unfair of me to imply any amount
of "reluctance" to submit the NFS/RDMA code for review. I was just
trying to gauge the "real soon now" type posts we've seen over the
past few months. If anything I'd imagine the latest NFS churn has
given you additional incentive to merge.
Thanks for your continued hard work; NFS/RDMA looks to be a huge
improvement for modern NFS deployments.
regards,
Mike
On Fri, 2007-04-13 at 16:47 -0400, Mike Snitzer wrote:
> I must be missing something because I don't see _any_ trace of the
> core RPC over RDMA support (xprtrdma et al), your RPC Transport
> Switch, or any of the other supporting changes in mainline. Could
> you, or others, please clarify the plan for merging RPC/RDMA?
That would be a question for the actual RPC/RDMA developers (i.e. James
Lentini and Tom Talpey). They haven't submitted any code for review yet.
> Do you mean the NFS/RDMA server code from Tom Tucker of Open Grid
> Computing? Why wouldn't this code be included?
That too has never been submitted for review AFAIK. Why would we include
it?
Cheers
Trond
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On 4/13/07, Chuck Lever <[email protected]> wrote:
> Mike Snitzer wrote:
> > On 2/2/07, Chuck Lever <[email protected]> wrote:
> >> Roland Dreier wrote:
> >> > > They are mostly from Chuck Level and make preparating for IPv6
> >> support
> >> > > in the NFS server.
> >> > > They are *not* for 2.6.20, but should be ok for .21.
> >> >
> >> > Out of curiousity, does this patch series reduce the delta between the
> >> > NFS/RDMA tree and mainline Linux? In other words does this bring
> >> > NFS/RDMA closer to merging?
> >>
> >> Hi Roland-
> >>
> >> The client side support for an RPC/RDMA module is almost completely
> >> integrated into mainline. There is still a minimal set of patches
> >> required to support alternate transports in loadable kernel modules
> >> which Trond has indicated he will integrate when the RPC/RDMA transport
> >> is ready to be integrated.
> >
> > Hi Chuck,
> >
> > I must be missing something because I don't see _any_ trace of the
> > core RPC over RDMA support (xprtrdma et al), your RPC Transport
> > Switch, or any of the other supporting changes in mainline. Could
> > you, or others, please clarify the plan for merging RPC/RDMA?
>
> The RPC transport switch patches are almost fully integrated into
> mainline. The xprtrdma piece is what is not there yet.
OK, has the xprtrdma piece been reviewed by the community? What, if
anything, is preventing the code from being included in -mm for wider
testing?
Has xprtrdma inclusion/progress been discussed on some other mailing
list? Any insight would be appreciated.
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs