WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] ring.h notification hold-off question

To: Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] ring.h notification hold-off question
From: Daniel Stodden <stodden@xxxxxxxxxx>
Date: Sat, 10 Nov 2007 06:37:47 +0100
Delivery-date: Fri, 09 Nov 2007 21:38:34 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Fakultät für Informatik I10, Technische Universität Münche
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>