On Tue, Aug 17, 2010 at 6:31 PM, Venkateswararao Jujjuri (JV)
<jvrao@xxxxxxxxxxxxxxxxxx> wrote:
>>>
>>> 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.
>
Actually, msize is supposed to be the maximum amount of data that gets
copied over the transport which should be a factor determined by the
client and server and the underlying technology which links them.
>From that aspect I think its a perfectly valid way to set this up and
is already part of the mechanisms.
>
> 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.
>
I don't know if I saw such a use in the existing patch. Can you give
me a concrete use case where we would use multiple "short" pages
instead of mostly full pages and potentially a single short page at
the end?
-eric
--
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
