qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 18/43] block: Switch discard length bounds to byt


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PULL 18/43] block: Switch discard length bounds to byte-based
Date: Wed, 6 Jul 2016 10:27:18 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 06.07.2016 um 04:14 hat Eric Blake geschrieben:
> On 07/05/2016 09:50 AM, Kevin Wolf wrote:
> > From: Eric Blake <address@hidden>
> > 
> > Sector-based limits are awkward to think about; in our on-going
> > quest to move to byte-based interfaces, convert max_discard and
> > discard_alignment.  Rename them, using 'pdiscard' as an aid to
> > track which remaining discard interfaces need conversion, and so
> > that the compiler will help us catch the change in semantics
> > across any rebased code.  The BlockLimits type is now completely
> > byte-based; and in iscsi.c, sector_limits_lun2qemu() is no
> > longer needed.
> > 
> 
> > +++ b/include/block/block_int.h
> > @@ -324,11 +324,17 @@ struct BlockDriver {
> >  };
> >  
> >  typedef struct BlockLimits {
> > -    /* maximum number of sectors that can be discarded at once */
> > -    int max_discard;
> > -
> > -    /* optimal alignment for discard requests in sectors */
> > -    int64_t discard_alignment;
> > +    /* maximum number of bytes that can be discarded at once (since it
> > +     * is signed, it must be < 2G, if set), should be multiple of
> > +     * pdiscard_alignment, but need not be power of 2. May be 0 if no
> > +     * inherent 32-bit limit */
> > +    int32_t max_pdiscard;
> > +
> > +    /* optimal alignment for discard requests in bytes, must be power
> > +     * of 2, less than max_pdiscard if that is set, and multiple of
> > +     * bs->request_alignment. May be 0 if bs->request_alignment is
> > +     * good enough */
> > +    uint32_t pdiscard_alignment;
> 
> Given the recent thread on an iscsi device with 15M optimum alignment
> for zero and discards, I guess I have some followup patches to write if
> we don't want to stall this pull request.

Please send a followup patch (series).

Does this one actually change the behaviour or just document the
behaviour that we already expected?

Kevin

Attachment: pgpYglgQ6fwtJ.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]