| Message ID | 20191211152956.5168-4-pdurrant@amazon.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 1ee54195a305fae3955642af8528bdf67496d353 |
| Headers | show |
| Series | xen-blkback: support live update | expand |
On 11.12.19 16:29, Paul Durrant wrote: > Currently these macros are defined to re-initialize a front/back ring > (respectively) to values read from the shared ring in such a way that any > requests/responses that are added to the shared ring whilst the front/back > is detached will be skipped over. This, in general, is not a desirable > semantic since most frontend implementations will eventually block waiting > for a response which would either never appear or never be processed. > > Since the macros are currently unused, take this opportunity to re-define > them to re-initialize a front/back ring using specified values. This also > allows FRONT/BACK_RING_INIT() to be re-defined in terms of > FRONT/BACK_RING_ATTACH() using a specified value of 0. > > NOTE: BACK_RING_ATTACH() will be used directly in a subsequent patch. > > Signed-off-by: Paul Durrant <pdurrant@amazon.com> Reviewed-by: Juergen Gross <jgross@suse.com> Juergen
On 12.12.19 07:04, Jürgen Groß wrote: > On 11.12.19 16:29, Paul Durrant wrote: >> Currently these macros are defined to re-initialize a front/back ring >> (respectively) to values read from the shared ring in such a way that any >> requests/responses that are added to the shared ring whilst the >> front/back >> is detached will be skipped over. This, in general, is not a desirable >> semantic since most frontend implementations will eventually block >> waiting >> for a response which would either never appear or never be processed. >> >> Since the macros are currently unused, take this opportunity to re-define >> them to re-initialize a front/back ring using specified values. This also >> allows FRONT/BACK_RING_INIT() to be re-defined in terms of >> FRONT/BACK_RING_ATTACH() using a specified value of 0. >> >> NOTE: BACK_RING_ATTACH() will be used directly in a subsequent patch. >> >> Signed-off-by: Paul Durrant <pdurrant@amazon.com> > > Reviewed-by: Juergen Gross <jgross@suse.com> Paul, I think you should send a patch changing ring.h in the Xen tree. As soon as it has been accepted I'll take your series for the kernel. Juergen
> -----Original Message----- > From: Jürgen Groß <jgross@suse.com> > Sent: 13 December 2019 09:00 > To: Durrant, Paul <pdurrant@amazon.com>; xen-devel@lists.xenproject.org; > linux-block@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>; Stefano Stabellini > <sstabellini@kernel.org> > Subject: Re: [PATCH v3 3/4] xen/interface: re-define > FRONT/BACK_RING_ATTACH() > > On 12.12.19 07:04, Jürgen Groß wrote: > > On 11.12.19 16:29, Paul Durrant wrote: > >> Currently these macros are defined to re-initialize a front/back ring > >> (respectively) to values read from the shared ring in such a way that > any > >> requests/responses that are added to the shared ring whilst the > >> front/back > >> is detached will be skipped over. This, in general, is not a desirable > >> semantic since most frontend implementations will eventually block > >> waiting > >> for a response which would either never appear or never be processed. > >> > >> Since the macros are currently unused, take this opportunity to re- > define > >> them to re-initialize a front/back ring using specified values. This > also > >> allows FRONT/BACK_RING_INIT() to be re-defined in terms of > >> FRONT/BACK_RING_ATTACH() using a specified value of 0. > >> > >> NOTE: BACK_RING_ATTACH() will be used directly in a subsequent patch. > >> > >> Signed-off-by: Paul Durrant <pdurrant@amazon.com> > > > > Reviewed-by: Juergen Gross <jgross@suse.com> > > Paul, I think you should send a patch changing ring.h in the Xen tree. > > As soon as it has been accepted I'll take your series for the kernel. > Ok. I was waiting for a push so that I could cite the commit hash but I'll prep something now instead. Paul
diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h index 3f40501fc60b..2af7a1cd6658 100644 --- a/include/xen/interface/io/ring.h +++ b/include/xen/interface/io/ring.h @@ -125,35 +125,24 @@ struct __name##_back_ring { \ memset((_s)->pad, 0, sizeof((_s)->pad)); \ } while(0) -#define FRONT_RING_INIT(_r, _s, __size) do { \ - (_r)->req_prod_pvt = 0; \ - (_r)->rsp_cons = 0; \ +#define FRONT_RING_ATTACH(_r, _s, _i, __size) do { \ + (_r)->req_prod_pvt = (_i); \ + (_r)->rsp_cons = (_i); \ (_r)->nr_ents = __RING_SIZE(_s, __size); \ (_r)->sring = (_s); \ } while (0) -#define BACK_RING_INIT(_r, _s, __size) do { \ - (_r)->rsp_prod_pvt = 0; \ - (_r)->req_cons = 0; \ - (_r)->nr_ents = __RING_SIZE(_s, __size); \ - (_r)->sring = (_s); \ -} while (0) +#define FRONT_RING_INIT(_r, _s, __size) FRONT_RING_ATTACH(_r, _s, 0, __size) -/* Initialize to existing shared indexes -- for recovery */ -#define FRONT_RING_ATTACH(_r, _s, __size) do { \ - (_r)->sring = (_s); \ - (_r)->req_prod_pvt = (_s)->req_prod; \ - (_r)->rsp_cons = (_s)->rsp_prod; \ +#define BACK_RING_ATTACH(_r, _s, _i, __size) do { \ + (_r)->rsp_prod_pvt = (_i); \ + (_r)->req_cons = (_i); \ (_r)->nr_ents = __RING_SIZE(_s, __size); \ -} while (0) - -#define BACK_RING_ATTACH(_r, _s, __size) do { \ (_r)->sring = (_s); \ - (_r)->rsp_prod_pvt = (_s)->rsp_prod; \ - (_r)->req_cons = (_s)->req_prod; \ - (_r)->nr_ents = __RING_SIZE(_s, __size); \ } while (0) +#define BACK_RING_INIT(_r, _s, __size) BACK_RING_ATTACH(_r, _s, 0, __size) + /* How big is this ring? */ #define RING_SIZE(_r) \ ((_r)->nr_ents)
Currently these macros are defined to re-initialize a front/back ring (respectively) to values read from the shared ring in such a way that any requests/responses that are added to the shared ring whilst the front/back is detached will be skipped over. This, in general, is not a desirable semantic since most frontend implementations will eventually block waiting for a response which would either never appear or never be processed. Since the macros are currently unused, take this opportunity to re-define them to re-initialize a front/back ring using specified values. This also allows FRONT/BACK_RING_INIT() to be re-defined in terms of FRONT/BACK_RING_ATTACH() using a specified value of 0. NOTE: BACK_RING_ATTACH() will be used directly in a subsequent patch. Signed-off-by: Paul Durrant <pdurrant@amazon.com> --- Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> A patch to add the FRONT/BACK_RING_ATTACH() macros to the canonical ring.h in xen.git will be sent once the definitions have been agreed. v2: - change definitions to take explicit initial index values --- include/xen/interface/io/ring.h | 29 +++++++++-------------------- 1 file changed, 9 insertions(+), 20 deletions(-)