qemu-block
[Top][All Lists]
Advanced

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

Re: [RFC v2] nbd/proto: introduce extended request and 64bit commands


From: Wouter Verhelst
Subject: Re: [RFC v2] nbd/proto: introduce extended request and 64bit commands
Date: Wed, 18 Mar 2020 09:04:54 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

On Wed, Mar 18, 2020 at 09:19:45AM +0300, Vladimir Sementsov-Ogievskiy wrote:
> > OK, understand. Reasonable thing, agreed. I'll resend.
> 
> Hmm. But we can't read in one go anyway, because we need to distinguish 
> NBD_REQUEST_MAGIC
> from NBD_EXTENDED_REQUEST_MAGIC..

Yes, that needs to happen at any rate, indeed. So the difference will be
two reads rather than three, instead of one read rather than two.

That's still an advantage.

> I think, that modern client will use mostly NBD_EXTENDED_REQUEST_MAGIC 
> interface, so it will
> be great to optimize it. But to read extended request in one go, we should 
> make it
> shorter than simple request, and it doesn't seem possible.
> 
> May be we should not support simple and extended requests together? May be 
> better to force
> using only extended requests if they are negotiated? Then we will read 
> extended request in
> on go, and we may just define it like
> 
> C: 32 bits, 0x23876289, magic (`NBD_EXTENDED_REQUEST_MAGIC`)
> C: 16 bits, flags
> C: 16 bits, type
> C: 64 bits, handle
> C: 32 bits, length of payload (unsigned), MUST be greater or equal to 16
> C: *length* bytes of payload data (if *length* is nonzero)
> 
> - so, we'll just read 36 bytes in one go, and then additional payload, if 
> length
> is more than 16.

That is, certainly, also an option, although I would define length of
payload to not include the offset and length bytes.

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22



reply via email to

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