>>> 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
