Re: [PATCH RFC v2 4/8] hw/block/nvme: try to deal with the iov/qsg duality

[Klaus Jensen]

On Feb  9 00:45, Keith Busch wrote:
> On Sun, Feb 07, 2021 at 10:49:36PM +0100, Klaus Jensen wrote:
> > From: Klaus Jensen <k.jensen@samsung.com>
> > 
> > Introduce NvmeSg and try to deal with that pesky qsg/iov duality that
> > haunts all the memory-related functions.
> > 
> > Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
> > ---
> >  hw/block/nvme.h |   8 ++-
> >  hw/block/nvme.c | 171 ++++++++++++++++++++++++------------------------
> >  2 files changed, 90 insertions(+), 89 deletions(-)
> > 
> > diff --git a/hw/block/nvme.h b/hw/block/nvme.h
> > index cb2b5175f1a1..0e4fbd6990ad 100644
> > --- a/hw/block/nvme.h
> > +++ b/hw/block/nvme.h
> > @@ -29,6 +29,11 @@ typedef struct NvmeAsyncEvent {
> >      NvmeAerResult result;
> >  } NvmeAsyncEvent;
> >  
> > +typedef struct NvmeSg {
> > +    QEMUSGList   qsg;
> > +    QEMUIOVector iov;
> > +} NvmeSg;
> 
> It's always one or the other, right? If so, this could be a 'union'
> type, and then you'd just need an indicator field to say which type it
> is. There may be a meaninful memory savings that way since we
> potentially allocate thousands of these.

Yes, that's true.

I'll do that for v3!

signature.asc
Description: PGP signature