Re: [Xen-devel] [Xen-users] Grant reference batch transmission

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-03-11 at 10:40 +0000, Gareth Stockwell wrote:
> On Wed, Mar 11, 2015 at 10:24:48, Ian Campbell wrote:
> > > I think this gives us two options for grant reference batch transmission:
> > >
> > > 1. Send the grant references via the ring buffer.
> > > This doesn't require any additional allocations, but means that if
> > > the number of grant references in the batch is greater than
> > > O(sizeof(ringbuffer) / sizeof(grant_ref_t)), cycling through the
> > > ring will be required.
> >
> > Correct. In fact it's a bit worse because the ring pointers steal a
> > bit of space out of the shared page. You might also find that in
> > practice you want an id in the request which is echoed back in the response 
> > e.g.
> > to handle out of order completion (depends on your use case though),
> > which would increase sizeof(grant_ref_t) (which is really sizeof(my_req_t)).
> >
> > What sorts of batch sizes are you expecting to see in your use case?
> 
> We need to share hundreds of MB, so (assuming a 4kB guest page size)
> the batch size can be thousands of grant references.

FWIW, the granularity of a gref is 4kB irrespective of the guest's page
size (so e.g. a 64Kb page would need 16 grefs to cover it), so your
calculation is correct everywhere.

We have been considering allow "superpage" grants of higher order
mappings, but no work has been done on that yet. You such a feature be
useful or are your hundreds of MB scattered?

I suppose the 100s of MB is changing reasonable often (e.g. not just a
start of day setup thing) otherwise the performance/efficiency of gref
communications wouldn't be such an issue.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel