hi. trying to understand the idea behind _notify in #define RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(_r, _notify) do { \ RING_IDX __old = (_r)->sring->req_prod; \ RING_IDX __new = (_r)->req_prod_pvt; \ wmb(); /* back sees requests /before/ updated producer index */ \ (_r)->sring->req_prod = __new; \ mb(); /* back sees new requests /before/ we check req_event */ \ (_notify) = ((RING_IDX)(__new - (_r)->sring->req_event) < \ (RING_IDX)(__new - __old)); \ } while (0) questions are regarding wrapping the ring indexes. a) to make sure: ring idx integer-wraps do happen, right? asking because the only mask operations i can find are those in the GET_REQUEST/RESPONSE macros. b) if __old were UINT_MAX, then the consumer side might/would set req_event to 0 after catching up right? (req_cons(== req_prod)+1) now assume __new == __old + 2 then we had req_event [0] < __new [1] < __old [INT_MAX] i.e. __new - req_event [1] > __new - __old [-1] i.e. _notify=false, which i believe skips a wanted notification. c) the case __old < __new < req_event (no wraps) would always notify. this somewhere contradicts the statement in ring.h regarding opportunities to customise FINAL_CHECK for for larger-than-one batches. if i''m wrong, then can anybode enlighten me, please? thanks for patience, daniel -- Daniel Stodden LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation Institut für Informatik der TU München D-85748 Garching http://www.lrr.in.tum.de/~stodden mailto:stodden@cs.tum.edu PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel Stodden
2007-Nov-10 05:51 UTC
[Xen-devel] Re: ring.h notification hold-off question
On Sat, 2007-11-10 at 06:37 +0100, Daniel Stodden wrote:> req_event [0] < __new [1] < __old [INT_MAX] > > i.e. > __new - req_event [1] > __new - __old [-1]uh, pardon, the -1 is wrong. but the rest i believe holds. -- Daniel Stodden LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation Institut für Informatik der TU München D-85748 Garching http://www.lrr.in.tum.de/~stodden mailto:stodden@cs.tum.edu PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/11/07 05:37, "Daniel Stodden" <stodden@cs.tum.edu> wrote:> b) if __old were UINT_MAX, then the consumer side might/would > set req_event to 0 after catching up right? (req_cons(== req_prod)+1) > now assume __new == __old + 2 then we had > > req_event [0] < __new [1] < __old [INT_MAX] > > i.e. > __new - req_event [1] > __new - __old [-1] > > i.e. _notify=false, which i believe skips a wanted notification.No. req_event==0, new==1, old==UINT_MAX. Then new-req_event==1, new-old==2. Hence a notification will be sent. Case (c) you are also wrong because after the subtractions we cast to an unsigned integer. Hence in the case old<new<req_event, new-req_event will be a large +ve integer, not a small -ve one. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel Stodden
2007-Nov-10 17:16 UTC
Re: [Xen-devel] ring.h notification hold-off question
On Sat, 2007-11-10 at 09:40 +0000, Keir Fraser wrote:> i.e. _notify=false, which i believe skips a wanted notification. > > No. req_event==0, new==1, old==UINT_MAX. Then new-req_event==1, new-old==2. > Hence a notification will be sent.unsigned. omygod. %}> Case (c) you are also wrong because after the subtractions we cast to an > unsigned integer. Hence in the case old<new<req_event, new-req_event will be > a large +ve integer, not a small -ve one.makes all sense then. sorry and thanks for the patience. regards, daniel -- Daniel Stodden LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation Institut für Informatik der TU München D-85748 Garching http://www.lrr.in.tum.de/~stodden mailto:stodden@cs.tum.edu PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel