Well, you misunderstood my reply too -- I just pointed out that having that notification in IOCP model will allow us to have best parts of both approaches.
On Mon, Mar 26, 2018 at 10:44 AM, Jameson Nash <[email protected]> wrote: > No, you misunderstood my reply. My analysis is not for a precise size, but > for the _minimum_ size write block required for the underlying protocol > details (such as MTU or ping time) to not be throttling the performance. By > all means, if you are memory constrained and don't care about bandwidth > utilization or performance, the `epoll` readiness model can help you. > Otherwise, your application would be wasting cycles computing data when it > could be transmitting and transmitting small packets when it could be > computing the next large chunk. > > > there will be waste of space as most user-level requests > Nope, I mentioned this already, but the minimum buffer size is chosen to > be substantially larger than the expected packet size, so that only a > small fraction of requests will not be sent with maximum size. > > > data flows to network buffer gets released in whatever granularity that > is right in given circumstances > True. I've tuned my numbers based on guesses and then added enough margin > that this wouldn't matter. But the underlying TCP protocol scales based on > network conditions, and you could also potentially dynamically size the > buffer based on the actual observed transfer rate. This wouldn't be a ring > buffer design anymore, and you would have to be careful to ensure that the > control-system isn't dynamically unstable, but it would be fairly > straightforward to re-compute the bandwidth in each uv_write_t / uv_read_t > callback and adjust the buffer size accordingly. > > If you are somehow severely memory constrained (even though memory is much > cheaper than processors and bandwidth), you can consider the problem in the > other direction. For example, say that you didn't have enough memory to > meet the minimum I previously posted, but instead had some smaller number > such as 64kB memory. If you split this up to get write notifications in > chunks of 4kB (1/16), that's still less than 6% memory overhead. > > > there is no wasted space > This isn't a real metric. There's space being used as storage, and space > being left unused for performance. I'm not "wasting" anything. > > In reply to: > >> Yes, I thought about TCP segment size/etc, but: >> - this means client has to be aware of underlying protocol details (and >> as it turns out there is no way to know precisely how large your TCP >> segment can be -- TCP header can have optional fields and things like VPN >> can get in a way too) >> - and make a correct call about granularity of buffers being submitted to >> IOCP >> - and even if it is completely correct -- there will be waste of space as >> most user-level requests (that needs to be sent out) won't fit the buffer >> perfectly >> >> now compare this to a situation where application maintain one ring >> buffer and simply adds to it and reuses portions released by fictional >> "buffer release" notification: >> - application doesn't need to be aware of underlying layer specifics -- >> as data flows to network buffer gets released in whatever granularity that >> is right in given circumstances >> - there is no wasted space (well, maybe you'd want to consider to align >> your data to avoid cpu cache line sharing) >> - kernel doesn't need to notify user code about every byte written out -- >> all it needs is to raise a flag and maintain a "data written out" counter; >> once client finally gets to process the notification -- he'll reclaim all >> buffer space already sent out in one go >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "libuv" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/libuv/BaFEVPyBUqU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/libuv. > For more options, visit https://groups.google.com/d/optout. > -- Sincerely yours, Michael. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
