From: Tom Talpey <tmtalpey@gmail.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Steve Wise <swise@opengridcomputing.com>,
tom@opengridcomputing.com, linux-nfs@vger.kernel.org,
vuhuong@mellanox.com
Subject: Re: [PATCH 2.6.30] xprtrdma: The frmr iova_start values are truncated by the nfs rdma client.
Date: Mon, 11 May 2009 21:14:34 -0400 [thread overview]
Message-ID: <4a08cd7b.48c3f10a.6bb1.fffff6d3@mx.google.com> (raw)
In-Reply-To: <1242089066.1743.19.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
At 08:44 PM 5/11/2009, Trond Myklebust wrote:
>On Mon, 2009-05-11 at 19:13 -0500, Steve Wise wrote:
>> Trond Myklebust wrote:
>> > On Mon, 2009-05-11 at 17:25 -0500, Steve Wise wrote:
>> >
>> >> Hey Trond,
>> >>
>> >> Will this bug fix make 2.6.30?
>> >>
>> >> Thanks,
>> >>
>> >> Steve.
>> >>
>> >
>> > Not in the form it is in now. As I've said earlier, I'm not happy about
>> > the sunrpc layer having to circumvent ordinary type checking on
>> > non-sunrpc structures.
>> >
>> > Cheers
>> > Trond
>> How is it circumventing? It's currently incorrectly casting a pointer
>> into a u64. That seems just broken to me. Also, its really the sunrpc
>> rdma transport layer. It deals specifically with rdma. It _should_
>> know about rdma interfaces and types.
>
>The fact is that I'm simply not interested enough in rdma to tolerate
>hacks. If it isn't done cleanly, in a manner that I can maintain, then
>the whole transport layer comes out...
I know exactly what you want - it's not what the code does now and
it's not an accessor function to set the hardware's u64 field. What's
needed is a new function to manage the entire RDMA triplet, and the
memory registration behind it, in the OFA code side. Put the hardware
goop below the line, IOW. I'll dust up Steve on this.
Tom.
next prev parent reply other threads:[~2009-05-12 1:14 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-24 19:05 [PATCH 2.6.30] xprtrdma: The frmr iova_start values are truncated by the nfs rdma client Steve Wise
[not found] ` <20090424190510.3134.90405.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
2009-04-25 14:11 ` Steve Wise
2009-04-26 18:57 ` Steve Wise
2009-04-27 2:17 ` Tom Talpey
[not found] ` <49f515a5.1d1e640a.1c82.6677-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-04-27 17:37 ` Steve Wise
2009-04-27 18:05 ` Trond Myklebust
[not found] ` <1240855510.8818.9.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-04-27 18:23 ` Trond Myklebust
[not found] ` <1240856613.8818.16.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-04-27 19:32 ` Steve Wise
2009-04-27 19:42 ` Tom Talpey
[not found] ` <49f60ac4.1c1d640a.2d0a.61a7-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-04-27 19:50 ` Steve Wise
2009-04-27 20:06 ` Tom Talpey
[not found] ` <49f61067.181e640a.3cb9.0e6c-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-04-27 20:20 ` Steve Wise
2009-04-27 20:46 ` Trond Myklebust
[not found] ` <1240865214.8818.73.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-04-27 20:49 ` Steve Wise
2009-05-11 22:25 ` Steve Wise
2009-05-11 22:50 ` Trond Myklebust
[not found] ` <1242082203.1743.11.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-05-12 0:13 ` Steve Wise
2009-05-12 0:23 ` Tom Talpey
[not found] ` <4a08c1b5.151e640a.0a99.fffff868-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-12 0:44 ` Steve Wise
2009-05-12 0:44 ` Trond Myklebust
[not found] ` <1242089066.1743.19.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-05-12 1:14 ` Tom Talpey [this message]
[not found] ` <4a08cd7b.48c3f10a.6bb1.fffff6d3-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-12 1:35 ` Trond Myklebust
[not found] ` <1242092150.16618.15.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-05-12 3:06 ` Steve Wise
2009-05-12 16:11 ` [ofa-general] " Steve Wise
2009-05-12 16:23 ` Steve Wise
2009-05-13 21:35 ` Roland Dreier
[not found] ` <adak54kr8iz.fsf-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
2009-05-14 7:22 ` Or Gerlitz
[not found] ` <4A0BC6A6.1070002-smomgflXvOZWk0Htik3J/w@public.gmane.org>
2009-05-14 13:41 ` Steve Wise
2009-05-14 13:45 ` Or Gerlitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4a08cd7b.48c3f10a.6bb1.fffff6d3@mx.google.com \
--to=tmtalpey@gmail.com \
--cc=linux-nfs@vger.kernel.org \
--cc=swise@opengridcomputing.com \
--cc=tom@opengridcomputing.com \
--cc=trond.myklebust@fys.uio.no \
--cc=vuhuong@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox