From: Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: cel's patches under development
Date: Tue, 10 Apr 2007 15:32:19 -0400
Message-ID: <1176233539.309.27.camel@heimdal.trondhjem.org>
References: <460852BB.4080503@oracle.com>
	<200704101722.13798.olaf.kirch@oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: nfs@lists.sourceforge.net
To: Olaf Kirch <olaf.kirch@oracle.com>
In-Reply-To: <200704101722.13798.olaf.kirch@oracle.com>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net

On Tue, 2007-04-10 at 17:22 +0200, Olaf Kirch wrote:
> Hi,
> The approach I'm trying is to leave the data in skb's for as long as it's
> practical, and copy data to the page cache in the XDR decode routines.
> In order to hide the skb mechanics, there's an rpc_data object that
> encapsulates this. It looks a little awkward, but Chuck complained
> about layering violations so I tried this instead.

I'm a bit wary of this. skbs are usually allocated from the ATOMIC pool
which is a very limited resource: their lifetime really wants to be as
short as possible. Won't this basically end up aggravating an already
nasty situation w.r.t. our behaviour when under memory pressure?

Also, what about stuff like RDMA, which doesn't need this sort of
mechanism in order to get things right?

Finally, will we need to keep writing these very complex handlers for
every new protocol that we want to add (e.g. IPv6, IPoIB, ...)?

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs