Re: [Qemu-devel] [PATCH 4/4] 9pfs: stat_to_qid: implement slow path

[Emilio G. Cota]

On Fri, Feb 09, 2018 at 16:22:33 +0100, Greg Kurz wrote:
> On Thu, 8 Feb 2018 19:00:19 +0100
> <address@hidden> wrote:
(snip)
> >  /* stat_to_qid needs to map inode number (64 bits) and device id (32 bits)
> >   * to a unique QID path (64 bits). To avoid having to map and keep track
> >   * of up to 2^64 objects, we map only the 16 highest bits of the inode plus
> > @@ -646,6 +695,10 @@ static int stat_to_qid(V9fsPDU *pdu, const struct stat 
> > *stbuf, V9fsQID *qidp)
> >  
> >      /* map inode+device to qid path (fast path) */
> >      err = qid_path_prefixmap(pdu, stbuf, &qidp->path);
> > +    if (err == -ENFILE) {
> > +        /* fast path didn't work, fal back to full map */
> > +        err = qid_path_fullmap(pdu, stbuf, &qidp->path);
> 
> Hmm... if we have already generate QIDs with fast path, how
> can we be sure we won't collide with the ones from the full
> map ?
> 
> IIRC, Emilio had suggested to use bit 63 to distinguish between
> fast and slow path.

Yep. Antonios: did you consider that approach? For reference:
  https://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg05084.html

That would make the fast path faster by just using bit masks, which I
think it's a superior approach if indeed the assumption about top bits
being zero in most cases is accurate.

                Emilio