From: Tom Tucker <tom@opengridcomputing.com>
To: Neil Brown <neilb@suse.de>
Cc: Tom Talpey <Thomas.Talpey@netapp.com>,
Linux NFS Mailing List <nfs@lists.sourceforge.net>,
Peter Leckie <pleckie@melbourne.sgi.com>,
Greg Banks <gnb@sgi.com>
Subject: Re: [RFC,PATCH 11/15] knfsd: RDMA transport core
Date: Mon, 21 May 2007 10:58:36 -0500 [thread overview]
Message-ID: <1179763116.23385.240.camel@trinity.ogc.int> (raw)
In-Reply-To: <18001.17958.145762.704892@notabene.brown>
On Mon, 2007-05-21 at 17:11 +1000, Neil Brown wrote:
> On Friday May 18, tom@opengridcomputing.com wrote:
> >
> > This file implements the core transport data management and I/O
> > path. The I/O path for RDMA involves receiving callbacks on interrupt
> > context. Since all the svc transport locks are _bh locks we enqueue the
> > transport on a list, schedule a tasklet to dequeue data indications from
> > the RDMA completion queue. The tasklet in turn takes _bh locks to
> > enqueue receive data indications on a list for the transport. The
> > svc_rdma_recvfrom transport function dequeues data from this list in an
> > NFSD thread context.
>
> Cannot we simply change the usage of ->sp_lock to always disable
> interrupts?
> That would make this much simpler. How much would it cost?
I don't think they are particularly expensive to acquire, but they add
incremental interrupt latency to the system. My impression is that the
general guidance from Linus et al is to avoid them if not absolutely
necessary. Trond's comments I think reflected this viewpoint as well,
but perhaps I'm just solving a problem that doesn't exist.
>
> Alternatively, why can the network layer deliver these notification in
> "bh" context, but the ib layer wants to deliver them in irq context?
> Does doing it in irq context have lower latency or something?
>
Yes, latency was certainly the design criteria in OFA. In practice, I
think we're talking nanoseconds (i.e. interrupt handler vs. tasklet),
however, when you're working with minimum latencies in the 2.8us range,
nanoseconds become statistically significant.
For our purposes, I don't think the latency is an issue.
> NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
prev parent reply other threads:[~2007-05-21 15:58 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-18 17:45 [RFC,PATCH 11/15] knfsd: RDMA transport core Tom Tucker
2007-05-18 19:07 ` Trond Myklebust
2007-05-18 20:07 ` Tom Tucker
2007-05-18 21:17 ` Trond Myklebust
2007-05-19 4:32 ` Tom Tucker
2007-05-21 7:16 ` Neil Brown
2007-05-21 16:02 ` Tom Tucker
2007-05-22 5:36 ` Neil Brown
2007-05-22 15:23 ` Tom Tucker
2007-05-18 19:24 ` J. Bruce Fields
2007-05-18 19:36 ` Tom Tucker
2007-05-18 19:42 ` J. Bruce Fields
2007-05-23 14:09 ` Greg Banks
2007-05-23 14:43 ` Tom Tucker
2007-05-23 14:55 ` Greg Banks
2007-05-23 15:03 ` Trond Myklebust
2007-05-23 15:12 ` Tom Tucker
2007-05-23 15:37 ` Trond Myklebust
2007-05-23 16:02 ` Tom Tucker
2007-05-23 16:35 ` Greg Banks
2007-05-23 16:29 ` Greg Banks
2007-05-23 18:07 ` Trond Myklebust
2007-05-23 18:19 ` Talpey, Thomas
2007-05-23 18:37 ` Trond Myklebust
2007-05-23 18:59 ` Talpey, Thomas
2007-05-23 20:01 ` Trond Myklebust
2007-05-23 21:00 ` Talpey, Thomas
2007-05-24 8:35 ` Greg Banks
2007-05-24 13:45 ` Talpey, Thomas
2007-05-23 15:03 ` Tom Tucker
2007-05-21 7:11 ` Neil Brown
2007-05-21 10:02 ` Greg Banks
2007-05-21 15:58 ` Tom Tucker [this message]
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=1179763116.23385.240.camel@trinity.ogc.int \
--to=tom@opengridcomputing.com \
--cc=Thomas.Talpey@netapp.com \
--cc=gnb@sgi.com \
--cc=neilb@suse.de \
--cc=nfs@lists.sourceforge.net \
--cc=pleckie@melbourne.sgi.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