Re: [PATCH 08/10] tools/xenstored: Extend restore code to handle multiple input buffer

[Juergen Gross <jgross@xxxxxxxx>]

On 24.06.21 10:42, Julien Grall wrote:
> Hi Juergen,
>
> On 24/06/2021 10:30, Juergen Gross wrote:
> > On 16.06.21 16:43, Julien Grall wrote:
> > > From: Julien Grall <jgrall@xxxxxxxxxx>
> > >
> > > Currently, the restore code is considering the stream will contain at
> > > most one in-flight request per connection. In a follow-up changes, we
> > > will want to transfer multiple in-flight requests.
> > >
> > > The function read_state_buffered() is now extended to restore multiple
> > > in-flight request. Complete requests will be queued as delayed
> > > requests, if there a partial request (only the last one can) then it
> > > will used as the current in-flight request.
> > >
> > > Note that we want to bypass the quota check for delayed requests as
> > > the new Xenstore may have a lower limit.
> > >
> > > Lastly, there is no need to change the specification as there was
> > > no restriction on the number of in-flight requests preserved.
> > >
> > > Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx>
> > > ---
> > >   tools/xenstore/xenstored_core.c | 56 ++++++++++++++++++++++++++++-----
> > >   1 file changed, 48 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/tools/xenstore/xenstored_core.c 
> > > b/tools/xenstore/xenstored_core.c
> > > index a5084a5b173d..5b7ab7f74013 100644
> > > --- a/tools/xenstore/xenstored_core.c
> > > +++ b/tools/xenstore/xenstored_core.c
> > > @@ -1486,6 +1486,10 @@ static void process_message(struct connection 
> > > *conn, struct buffered_data *in)
> > >       enum xsd_sockmsg_type type = in->hdr.msg.type;
> > >       int ret;
> > > +    /* At least send_error() and send_reply() expects 
conn->in == in */
> > > +    assert(conn->in == in);
> > > +    trace_io(conn, in, 0);
> > > +
> > >       if ((unsigned int)type >= XS_TYPE_COUNT|| !wire_funcs[type].func) 
> > {
> > >           eprintf("Client unknown operation %i", type);
> > >           send_error(conn, ENOSYS);
> > > @@ -1515,6 +1519,23 @@ static void process_message(struct connection 
> > > *conn, struct buffered_data *in)
> > >       conn->transaction = NULL;
> > >   }
> > > +static bool process_delayed_message(struct delayed_request *req)
> > > +{
> > > +    struct connection *conn = req->data;
> > > +    struct buffered_data *saved_in = conn->in;
> > > +
> > > +    /*
> > > +     * Part of process_message() expects conn->in to contains the
> > > +     * processed response. So save the current conn->in and restore it
> > > +     * afterwards.
> > > +     */
> > > +    conn->in = req->in;
> > > +    process_message(req->data, req->in);
> > > +    conn->in = saved_in;
> > This pattern was added to do_lu_start() already, and it will be needed
> > for each other function being called via call_delayed().
> >
> > Maybe it would be better to add conn explicitly to struct
> > delayed_request (or even better: replace data with conn) and to do the
> > conn->in saving/setting/restoring in call_delayed() instead?
> This was my original approach, but I abandoned it because in the case of 
> do_lu_start() we need to save the original conn->in in the stream (see 
> patch #3 for more details).
> If we overwrite conn->in in call_delayed(), then we need a different way 
> to find the original conn->in. I couldn't find a nice way and decided to 
> settle with the duplication.
Ah, okay, understood. Even in case we'd be able to restore conn->in it
would be the same amount of code again, but harder to follow.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature