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 <ericvh@xxxxxxxxx> wrote: >> On Tue, Aug 17, 2010 at 12:27 PM, Venkateswararao Jujjuri (JV) >> <jvrao@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx >> https://lists.sourceforge.net/lists/listinfo/v9fs-developer >> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
