public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Tom Talpey <tmtalpey@gmail.com>
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:35:50 -0400	[thread overview]
Message-ID: <1242092150.16618.15.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <4a08cd7b.48c3f10a.6bb1.fffff6d3-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>

On Mon, 2009-05-11 at 21:14 -0400, Tom Talpey wrote:
> 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.

This does indeed sound like what I'd looking for.

There is a huge difference between having code that depends on well
defined rdma interfaces, and code that depends on rdma hacks. A piece of
code that requires casts from a non-local opaque type into another
protocol-dependent non-local type will definitely fall in the latter
category. I really don't care what the current code does, but a fix for
that code is something that does it _correctly_; it is not yet another
hack, whether or not it fixes a bug in the short term.

   Trond


  parent reply	other threads:[~2009-05-12  1:35 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
     [not found]                                         ` <4a08cd7b.48c3f10a.6bb1.fffff6d3-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-12  1:35                                           ` Trond Myklebust [this message]
     [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=1242092150.16618.15.camel@heimdal.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=linux-nfs@vger.kernel.org \
    --cc=swise@opengridcomputing.com \
    --cc=tmtalpey@gmail.com \
    --cc=tom@opengridcomputing.com \
    --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