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 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.
