qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH v2 15/17] block: Switch discard length bounds to


From: Eric Blake
Subject: Re: [Qemu-block] [PATCH v2 15/17] block: Switch discard length bounds to byte-based
Date: Thu, 16 Jun 2016 08:21:24 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 06/15/2016 11:46 PM, Fam Zheng wrote:
> On Tue, 06/14 15:30, Eric Blake wrote:
>> 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.  In iscsi.c, sector_limits_lun2qemu()
>> is no longer needed; and the BlockLimits type is now completely
>> byte-based.
>>
>> Signed-off-by: Eric Blake <address@hidden>
>>

>>
>>  typedef struct BlockLimits {
>> -    /* maximum number of sectors that can be discarded at once */
>> -    int max_discard;
>> +    /* 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;
> 
> Why not use uint32_t?
> 
>>
>> -    /* optimal alignment for discard requests in sectors */
>> -    int64_t discard_alignment;
>> +    /* optimal alignment for discard requests in bytes, must be power
>> +     * of 2, less than max_discard if that is set, and multiple of
>> +     * bs->request_alignment. May be 0 if bs->request_alignment is
>> +     * good enough */
>> +    uint32_t pdiscard_alignment;
>>
>>      /* maximum number of bytes that can zeroized at once (since it is
>> -     * signed, it must be < 2G, if set) */
>> +     * signed, it must be < 2G, if set), should be multiple of
>> +     * pwrite_zeroes_alignment. May be 0 if no inherent 32-bit limit */
>>      int32_t max_pwrite_zeroes;

Because max_pwrite_zeroes didn't.

And because we're still limited by INT_MAX (or it's alternative spelling
BDRV_REQUEST_MAX_SECTORS).

Maybe we should switch both to uint32_t, but that can be a followup.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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