linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>
To: Latchesar Ionkov <lucho@ionkov.net>
Cc: Eric Van Hensbergen <ericvh@gmail.com>,
	linux-fsdevel@vger.kernel.org,
	v9fs-developer@lists.sourceforge.net,
	Badari Pulavarty <pbadari@us.ibm.com>
Subject: Re: [V9fs-developer] [PATCH 1/5] [net/9p] Add capability() to p9_trans_module
Date: Tue, 17 Aug 2010 16:31:56 -0700	[thread overview]
Message-ID: <4C6B1BEC.7020902@linux.vnet.ibm.com> (raw)
In-Reply-To: <AANLkTimxjUc-ZxD93MRHrjrw96YgJa4FPikHEU3QwiD+@mail.gmail.com>

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@gmail.com> wrote:
>> On Tue, Aug 17, 2010 at 12:27 PM, Venkateswararao Jujjuri (JV)
>> <jvrao@linux.vnet.ibm.com> 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
>>



  reply	other threads:[~2010-08-17 23:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-17 17:27 [00/05] Add zero copy capability to virtio transport Venkateswararao Jujjuri (JV)
2010-08-17 17:27 ` [PATCH 1/5] [net/9p] Add capability() to p9_trans_module Venkateswararao Jujjuri (JV)
2010-08-17 20:43   ` [V9fs-developer] " Eric Van Hensbergen
2010-08-17 20:46     ` Latchesar Ionkov
2010-08-17 23:31       ` Venkateswararao Jujjuri (JV) [this message]
2010-08-18 15:16         ` Eric Van Hensbergen
2010-08-18 16:56           ` Venkateswararao Jujjuri (JV)
2010-08-18 18:26             ` Eric Van Hensbergen
2010-08-17 17:27 ` [PATCH 2/5] [net/9p] Pass p9_client structure to pdu perpartion routines Venkateswararao Jujjuri (JV)
2010-08-17 17:27 ` [PATCH 3/5] [net/9p] Add support for placing page addresses directly on the sg list Venkateswararao Jujjuri (JV)
2010-08-18 20:50   ` [V9fs-developer] " Latchesar Ionkov
2010-08-19 18:28     ` Venkateswararao Jujjuri (JV)
2010-08-19 18:49       ` Latchesar Ionkov
2010-08-19 20:47         ` Venkateswararao Jujjuri (JV)
2010-08-19 21:07           ` Latchesar Ionkov
2010-08-19 21:26             ` Eric Van Hensbergen
2010-08-19 23:35               ` Venkateswararao Jujjuri (JV)
2010-08-20  0:27                 ` Eric Van Hensbergen
2010-08-17 17:27 ` [PATCH 4/5] [net/9p] Achieve zero copy on write path Venkateswararao Jujjuri (JV)
2010-08-19 19:30   ` [V9fs-developer] " Latchesar Ionkov
2010-08-19 20:55     ` Venkateswararao Jujjuri (JV)
2010-08-17 17:27 ` [PATCH 5/5] [net/9p] Achieve zero copy on read path Venkateswararao Jujjuri (JV)

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=4C6B1BEC.7020902@linux.vnet.ibm.com \
    --to=jvrao@linux.vnet.ibm.com \
    --cc=ericvh@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lucho@ionkov.net \
    --cc=pbadari@us.ibm.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    /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;
as well as URLs for NNTP newsgroup(s).