Hi, On Thu, Sep 03, 2015 at 09:55:37PM +0200, Wouter Verhelst wrote: > Hi Markus, > > On Thu, Aug 20, 2015 at 04:35:41PM +0200, Markus Pargmann wrote: > > On Thu, Aug 20, 2015 at 03:44:41PM +0200, Wouter Verhelst wrote: > > > On Thu, Aug 20, 2015 at 03:17:54PM +0200, Markus Pargmann wrote: > > > > I like the idea of blocks. However I think it would be better to have > > > > some kind of negotiation for the maximum block size for reads and > > > > writes. > > > > > > > > As the server can choose the size of a block itself I think it wouldn't > > > > be a problem to have a header for each data block which has the > > > > error state and so on. Then we wouldn't have this strange semantic of > > > > reporting the error state of the data we already transmitted. > > > > > > That would make doing things like using sendfile() to send out the > > > actual data impossible, as when you use sendfile(), you don't know that > > > an error occurred until you've put some of the data on the wire already. > > > > > > (unless I'm missing things, which of course is possible) > > > > Ah, I see. > > > > I still like the idea of fragmented replies. May be useful for NBD on > > top of UDP at some point (no real plans right now, but who knows... > > would be perfect for bootloader nbd implementations ;) ). > > We could of course use fragmented replies, I'm not opposed to that. > However, I think it's not very useful to have the client and the server > negotiate the fragment size. If the client doesn't want replies over a > given size, it should just not issue a read request that is too large. > The server should just send the data it wants to send; if a request is > too large to fit in memory, it should just not try to store it in memory > (which is the whole reason why I was proposing this change). > > The point about large requests causing wasted bandwidth in case of an > error somewhere halfway through does hold some merit, however, and so I > can imagine we might want to add fragmented replies in the protocol; but > if we're going to do so, we should just hardcode the maximum reply size > and be done with it. That reply size should be not too large (bandwidth > thing), but also not be too small (so that we don't engage the CPU in > too much context switching between "send data" and "send next header"). Yes I agree. If at some point it would be interesting to have it configurable, we would still be able to add a simple option for that. And UDP is probably not so interesting after some thoughts about it ;). Best Regards, Markus > > > > > Also when using blocks with block headers an offset would be good > > > > together with the length of the data. > > > > > > > > However this whole block thing would probably not be backwards > > > > compatible. > > > > > > None of this would be, hence the idea of adding a READ2 command, and > > > retaining READ for backwards compatibility. > > > > Yes, just for naming I would prefer something like READ_END instead of > > READ2. I am still thinking about this and other possibilities. > > Fair enough, I'll be the first to admit the name wasn't carefully chosen > ;-) > > -- > It is easy to love a country that is famous for chocolate and beer > > -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: Digital signature