Re: [Nbd] request queue

[Wouter Verhelst <w@...112...>]

On Tue, Mar 12, 2013 at 09:47:02AM +0100, folkert wrote:
> > > What about adding something to the NBD protocol which tells the server
> > > that x requests are coming in and that the client will not wait for an
> > > acknowledgement before it has send all requests and/or data for those x
> > > requests?
> > > Because then a server can pull in all requests in one go and then start
> > > to fiddle with the disk. Or do things intelligent in parallel (if you
> > > have multiple spindels). etc.
> > 
> > I don't see why we need to change the protocol for that? It's already
> > possible to handle requests in parallel. The client can (and does)
> > alrady have multiple outstanding requests; it's just that the current
> > server implementation doesn't handle them in parallel.
> 
> Problem is that a server does not know that it can wait for more
> requests to come in for which it can wait.

I don't see how this is a problem?

If there are no more requests outstanding, select() returns that the
socket is not ready for reading, and read() (if the socket is
nonblocking) returns EWOULDBLOCK. That's all you need, no?

> With the enhancement it knows that it can input multiple requests and
> then process them.  Like iSCSI does.

I don't see the benefit of adding something like that to the protocol.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.