Re: [Nbd] [RFC] Proposal: NBD_CMD_READ2
- To: Markus Pargmann <mpa@...1897...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>
- Subject: Re: [Nbd] [RFC] Proposal: NBD_CMD_READ2
- From: Wouter Verhelst <w@...112...>
- Date: Sun, 27 Sep 2015 19:06:32 +0200
- Message-id: <20150927170632.GA27037@...3...>
- In-reply-to: <20150924055258.GP32203@...1897...>
- References: <20150820110519.GA17039@...3...> <AE44BFF5-25F7-495E-80AA-A91947526A2A@...872...> <20150820131754.GE18784@...1897...> <20150820134441.GB27381@...3...> <20150820143541.GF18784@...1897...> <20150903195537.GH8621@...3...> <20150924055258.GP32203@...1897...>
On Thu, Sep 24, 2015 at 07:52:58AM +0200, Markus Pargmann wrote:
> Hi,
>
> On Thu, Sep 03, 2015 at 09:55:37PM +0200, Wouter Verhelst wrote:
> > 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 ;).
Right.
So that only leaves the question as to what the best fragment size is
(bikeshed alert).
It might make sense to have the size of a "frame" (reply header plus
data) line up with a 9000-byte boundary, so that it aligns with the MTU
of a jumbo frame as well as a regular 1500-byte ethernet frame. Only I
think 9000 bytes is too small; it should be a few orders of magnitude
higher.
How about 900000? That's just shy of one MiB, so should be plenty for
most requests (at least before I fixed the 1MiB buffer overflow that
became CVE-2005-3534 as well as CVE-2011-0530, the overflow was rare
enough that most people didn't easily encounter it)
Regards,
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Reply to: