From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Venkateswararao Jujjuri (JV)" Subject: Re: [V9fs-developer] [PATCH 1/5] [net/9p] Add capability() to p9_trans_module Date: Tue, 17 Aug 2010 16:31:56 -0700 Message-ID: <4C6B1BEC.7020902@linux.vnet.ibm.com> References: <1282066045-3945-1-git-send-email-jvrao@linux.vnet.ibm.com> <1282066045-3945-2-git-send-email-jvrao@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Eric Van Hensbergen , linux-fsdevel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, Badari Pulavarty To: Latchesar Ionkov Return-path: Received: from e32.co.us.ibm.com ([32.97.110.150]:37534 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751219Ab0HQXcJ (ORCPT ); Tue, 17 Aug 2010 19:32:09 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o7HNNphG025647 for ; Tue, 17 Aug 2010 17:23:51 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o7HNW050207352 for ; Tue, 17 Aug 2010 17:32:02 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o7HNVx16024974 for ; Tue, 17 Aug 2010 17:32:00 -0600 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Latchesar Ionkov wrote: > Or call the function once when the client is created and store the > value in the client struct. I don't think the call will be inlined. I think we can do this. Add a filed in the p9_client structure and do this call during client initialization.. > > Thanks, > Lucho > > On Tue, Aug 17, 2010 at 2:43 PM, Eric Van Hensbergen wrote: >> On Tue, Aug 17, 2010 at 12:27 PM, Venkateswararao Jujjuri (JV) >> wrote: >>> Every transport layer may have unique capabilities. This function is employed >>> to query and make use of those special/unique cabailities. >>> To start with we will be defining P9_CAP_GET_MAX_SG_PAGES. >>> If capability(P9_CAP_GET_MAX_SG_PAGES) exists AND returns a value greater >>> than 0, it means that the transport can support the transportation >>> of that many mapped pages between the client and server. >>> >> Is there a good reason to make this a function versus a flag/bit-mask >> in the transport structure? Having to call an extra function >> (hopefully it gets inlined, but its function pointer so I'm thinking >> it won't) every client_rpc call seems like a mistake. >> >> Additionally, given we know the page size constant, couldn't we infer >> this from a negotiated msize? Transports already have an maxsize >> field which limits the msize selections (and defaults? if not maybe it >> should?) -- why not just use that? The IO size in this mode is derived by virtio ring size rather than the msize. msize is restricted to the maximum amount of data that gets copied on the the kmalloc'd buffer. In this case it is just the header. I think moving the #of pages that can be accommodated onto the virtio ring to the p9_client, we can use it along with the page_size to determine how much data we are passing. With this we can tune our calculations on the read/write side .. so that we can derive better logic to handle short reads. Thanks, JV >> >> -eric >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> V9fs-developer mailing list >> V9fs-developer@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/v9fs-developer >>