netdev - Re: [RFC PATCH 4/9] vringh: unify the APIs for all accessors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANXvt5pRy-i7=_ikNkZPp2HcRmWZYNJYpjO_ieBJJVc90nds+A@mail.gmail.com>
Date:   Tue, 27 Dec 2022 16:49:21 +0900
From:   Shunsuke Mie <mie@...l.co.jp>
To:     "Michael S. Tsirkin" <mst@...hat.com>
Cc:     Jason Wang <jasowang@...hat.com>,
        Rusty Russell <rusty@...tcorp.com.au>, kvm@...r.kernel.org,
        virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 4/9] vringh: unify the APIs for all accessors

2022年12月27日(火) 16:04 Michael S. Tsirkin <mst@...hat.com>:
>
> On Tue, Dec 27, 2022 at 11:25:26AM +0900, Shunsuke Mie wrote:
> > Each vringh memory accessors that are for user, kern and iotlb has own
> > interfaces that calls common code. But some codes are duplicated and that
> > becomes loss extendability.
> >
> > Introduce a struct vringh_ops and provide a common APIs for all accessors.
> > It can bee easily extended vringh code for new memory accessor and
> > simplified a caller code.
> >
> > Signed-off-by: Shunsuke Mie <mie@...l.co.jp>
> > ---
> >  drivers/vhost/vringh.c | 667 +++++++++++------------------------------
> >  include/linux/vringh.h | 100 +++---
> >  2 files changed, 225 insertions(+), 542 deletions(-)
> >
> > diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
> > index aa3cd27d2384..ebfd3644a1a3 100644
> > --- a/drivers/vhost/vringh.c
> > +++ b/drivers/vhost/vringh.c
> > @@ -35,15 +35,12 @@ static __printf(1,2) __cold void vringh_bad(const char *fmt, ...)
> >  }
> >
> >  /* Returns vring->num if empty, -ve on error. */
> > -static inline int __vringh_get_head(const struct vringh *vrh,
> > -                                 int (*getu16)(const struct vringh *vrh,
> > -                                               u16 *val, const __virtio16 *p),
> > -                                 u16 *last_avail_idx)
> > +static inline int __vringh_get_head(const struct vringh *vrh, u16 *last_avail_idx)
> >  {
> >       u16 avail_idx, i, head;
> >       int err;
> >
> > -     err = getu16(vrh, &avail_idx, &vrh->vring.avail->idx);
> > +     err = vrh->ops.getu16(vrh, &avail_idx, &vrh->vring.avail->idx);
> >       if (err) {
> >               vringh_bad("Failed to access avail idx at %p",
> >                          &vrh->vring.avail->idx);
>
> I like that this patch removes more lines of code than it adds.
>
> However one of the design points of vringh abstractions is that they were
> carefully written to be very low overhead.
> This is why we are passing function pointers to inline functions -
> compiler can optimize that out.
>
> I think that introducing ops indirect functions calls here is going to break
> these assumptions and hurt performance.
> Unless compiler can somehow figure it out and optimize?
> I don't see how it's possible with ops pointer in memory
> but maybe I'm wrong.
I think your concern is correct. I have to understand the compiler
optimization and redesign this approach If it is needed.
> Was any effort taken to test effect of these patches on performance?
I just tested vringh_test and already faced little performance reduction.
I have to investigate that, as you said.

Thank you for your comments.
> Thanks!
>
>
Best,
Shunsuke.