[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0001/001] xen: multi page ring support for block devices



>>> On 15.03.12 at 09:51, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Thu, 2012-03-15 at 08:03 +0000, Jan Beulich wrote:
>> >>> On 14.03.12 at 18:01, Justin Gibbs <justing@xxxxxxxxxxxxxxxx> wrote:
>> > While we're talking about fixing ring data structures, can RING_IDX
>> > be defined as a "uint32_t" instead of "unsigned int".  The structure
>> > padding in the ring macros assumes RING_IDX is exactly 4 bytes,
>> > so this should be made explicit.  ILP64 machines may still be a way
>> > out, but the use of non-fixed sized types in places where size really
>> > matters just isn't clean.
>> 
>> Yes, if we're going to rev the interface, then any such flaws should be
>> corrected.
> 
> There has been talk of doing something similar for netif too. IIRC the
> netchannel2 work included a new generic ring scheme with support for
> variable sized req/rsp elements and such.
> 
> If we are going to rev the rings then should we try and use a common
> ring mechanism? I think so. If so then we could do worse than to start
> from the netchannel2 ring stuff and/or concepts?
> 
> Looks like that is
> http://xenbits.xen.org/ext/netchannel2/linux-2.6.18/log/075f6677a290/include 
> /xen/interface/io/uring.h
> still a bit nc2 specific though.

Taking the concept (and the implementation as a starting point) would
seem like a good idea to me. Separate request and reply rings as well
as variable size entries would certainly benefit blkif too.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.