All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: Greg Kurz <groug@kaod.org>
Subject: Re: [PATCH v4 06/11] tests/virtio-9p: added splitted readdir test
Date: Wed, 22 Jan 2020 23:36:22 +0100	[thread overview]
Message-ID: <17952898.t909x8hp7r@silver> (raw)
In-Reply-To: <20200122221905.055f9f93@bahia.lan>

On Mittwoch, 22. Januar 2020 22:19:05 CET Greg Kurz wrote:
> On Tue, 21 Jan 2020 01:16:21 +0100
> 
> Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > The previous, already existing readdir test simply used a 'count'
> > parameter big enough to retrieve all directory entries with a
> > single Treaddir request.
> > 
> > In this new 'splitted' readdir test, directory entries are
> > retrieved, splitted over several Treaddir requests by picking small
> > 'count' parameters which force the server to truncate the response.
> > So the test client sends as many Treaddir requests as necessary to
> > get all directory entries. Currently this test covers actually two
> > tests: a sequence of Treaddir requests with count=512 and then a
> > subsequent test with a sequence of Treaddir requests with count=256.
> > 
> > Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> > ---
> 
> Not sure it is really needed to check with multiple values for 'count',
> but it doesn't eat too many cycles so I guess it doesn't hurt.

Yes, it is a cheap test, nobody will feel the difference. One could argue 
about the precise 'count' values being used ...

> 
> Applied as well.
> 
> >  tests/qtest/virtio-9p-test.c | 91 ++++++++++++++++++++++++++++++++++++
> >  1 file changed, 91 insertions(+)
> > 
> > diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
> > index 2167322985..8b0d94546e 100644
> > --- a/tests/qtest/virtio-9p-test.c
> > +++ b/tests/qtest/virtio-9p-test.c
> > @@ -578,6 +578,7 @@ static bool fs_dirents_contain_name(struct V9fsDirent
> > *e, const char* name)> 
> >      return false;
> >  
> >  }
> > 
> > +/* basic readdir test where reply fits into a single response message */
> > 
> >  static void fs_readdir(void *obj, void *data, QGuestAllocator *t_alloc)
> >  {
> >  
> >      QVirtio9P *v9p = obj;
> > 
> > @@ -631,6 +632,95 @@ static void fs_readdir(void *obj, void *data,
> > QGuestAllocator *t_alloc)> 
> >      g_free(wnames[0]);
> >  
> >  }
> > 
> > +/* readdir test where overall request is splitted over several messages
> > */
> > +static void fs_readdir_split(void *obj, void *data, QGuestAllocator
> > *t_alloc) +{
> > +    QVirtio9P *v9p = obj;
> > +    alloc = t_alloc;
> > +    char *const wnames[] = { g_strdup(QTEST_V9FS_SYNTH_READDIR_DIR) };
> > +    uint16_t nqid;
> > +    v9fs_qid qid;
> > +    uint32_t count, nentries, npartialentries;
> > +    struct V9fsDirent *entries, *tail, *partialentries;
> > +    P9Req *req;
> > +    int subtest;
> > +    int fid;
> > +    uint64_t offset;
> > +    /* the Treaddir 'count' parameter values to be tested */
> > +    const uint32_t vcount[] = { 512, 256 };

... here. But IMO it does make sense preserving the function's overall 
structure to allow testing with different 'count' values if necessary. Because 
that way this test could e.g. guard potential bugs when server's Treaddir 
handler is rolling back (or not) the dir offset for instance, which server has 
to do (or not) according to this 'count' value and the precise file name 
length of the individual directory entries.

Whatever precise 'count' tests are desired, it would only mean a one line 
change here.

Best regards,
Christian Schoenebeck




  reply	other threads:[~2020-01-22 22:38 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-21  0:36 [PATCH v4 00/11] 9pfs: readdir optimization Christian Schoenebeck
2020-01-20 22:29 ` [PATCH v4 01/11] tests/virtio-9p: add terminating null in v9fs_string_read() Christian Schoenebeck
2020-01-20 22:47 ` [PATCH v4 02/11] 9pfs: require msize >= 4096 Christian Schoenebeck
2020-01-20 23:50 ` [PATCH v4 03/11] 9pfs: validate count sent by client with T_readdir Christian Schoenebeck
2020-01-22 14:11   ` Greg Kurz
2020-01-22 14:26     ` Christian Schoenebeck
2020-01-21  0:01 ` [PATCH v4 04/11] hw/9pfs/9p-synth: added directory for readdir test Christian Schoenebeck
2020-01-21  0:12 ` [PATCH v4 05/11] tests/virtio-9p: added " Christian Schoenebeck
2020-01-22 19:56   ` Greg Kurz
2020-01-21  0:16 ` [PATCH v4 06/11] tests/virtio-9p: added splitted " Christian Schoenebeck
2020-01-22 21:14   ` Eric Blake
2020-01-22 21:29     ` Christian Schoenebeck
2020-01-23  6:59       ` Greg Kurz
2020-01-22 21:19   ` Greg Kurz
2020-01-22 22:36     ` Christian Schoenebeck [this message]
2020-01-23 10:30       ` Greg Kurz
2020-01-23 13:07         ` Christian Schoenebeck
2020-01-21  0:17 ` [PATCH v4 07/11] tests/virtio-9p: failing " Christian Schoenebeck
2020-01-22 22:59   ` Greg Kurz
2020-01-23 11:36     ` Christian Schoenebeck
2020-01-23 12:08       ` Greg Kurz
2020-01-21  0:23 ` [PATCH v4 08/11] 9pfs: readdir benchmark Christian Schoenebeck
2020-01-23 10:34   ` Greg Kurz
2020-01-23 13:20     ` Christian Schoenebeck
2020-01-21  0:26 ` [PATCH v4 09/11] hw/9pfs/9p-synth: avoid n-square issue in synth_readdir() Christian Schoenebeck
2020-01-23 11:13   ` Greg Kurz
2020-01-23 12:40     ` Christian Schoenebeck
2020-01-21  0:30 ` [PATCH v4 10/11] 9pfs: T_readdir latency optimization Christian Schoenebeck
2020-01-23 11:33   ` Greg Kurz
2020-01-23 12:57     ` Christian Schoenebeck
2020-03-09 14:09   ` Christian Schoenebeck
2020-03-09 15:42     ` Greg Kurz
2020-03-10 15:10       ` Christian Schoenebeck
2020-03-10 18:33         ` Greg Kurz
2020-03-11  1:18           ` Christian Schoenebeck
     [not found]             ` <20200311171408.3b3a2dfa@bahia.home>
2020-03-11 19:54               ` Christian Schoenebeck
2020-03-17 14:14                 ` Greg Kurz
2020-03-17 16:09                   ` Christian Schoenebeck
2020-01-21  0:32 ` [PATCH v4 11/11] hw/9pfs/9p.c: benchmark time on T_readdir request Christian Schoenebeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17952898.t909x8hp7r@silver \
    --to=qemu_oss@crudebyte.com \
    --cc=groug@kaod.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.