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.jen...@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.jen...@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
