src: Limit data frame payload size

[mxinden]

By limitting the data frame payload size one gains the following
beneftis:

1. Reduce delays sending time-sensitive frames, e.g. window updates.

2. Minimize head-of-line blocking across streams.

3. Enable better interleaving of send and receive operations, as each is
   carried out atomically instead of concurrently with its respective
   counterpart.

Limiting the frame size to 16KiB does not introduce a large overhead. A
Yamux frame header is 12 bytes large, thus this change introduces an
overhead of ~0.07%.

See #100 (comment) and comments below that for details.

Might reduce probability for #104 to happen.

[romanb]

Looks good to me, though I would prefer for this size to be configurable. It can then also be configurable in rust-libp2p in an analogous way to the "split send size" that is configurable for libp2p-mplex and currently defaults to 8KiB after measurement results very similar to yours for yamux. But I don't insist and leave it up to you.

[mxinden]

though I would prefer for this size to be configurable.

Can you think of a scenario where one would want to configure the limit?

[romanb]

Can you think of a scenario where one would want to configure the limit?

If you consider your benchmark results to be representative in every case, then no. I just tend to be a bit more cautious in that different people may see a different optimum in different constellations and configurations of their networking stack and hence would allow them to experiment with this setting for themselves, should they want to do so.

[mxinden]

If you consider your benchmark results to be representative in every case, then no.

You are right, I do not.

7a77cfb makes the limit configurable. I tried to mirror the mplex naming while keeping the Yamux conventions. As you usually have a good eye for easy-to-grasp documentation, let me know if you have suggestions for alternative wording @romanb.

[romanb]

Limiting the frame size to 16KiB does not introduce a large overhead.

Maybe not in terms of bandwidth, but at least the test tests/concurrent.rs seems to show that somewhat as expected, the smaller the frame size, the slower the test. For example, on the branch of #112 where the test uses a 128KiB payload size the test takes ~1 second with a 128KiB frame size, but ~4s with a 16KiB frame size (on my machine, debug mode). The difference is less pronounced in release mode (~0.4s vs ~0.6s). Very similar numbers for develop where the test current uses 100KiB payloads (but actually stalls very often with >=128KiB frame sizes unless one configures a generous TCP send buffer - a problem that is no longer present in #112). I guess a somewhat noticeable difference in CPU time is to be expected due to the significant increase in function calls (and probably system calls as well). I'm not suggesting that it outweighs the benefits, but it shows that is was probably a good idea to make the size at which frames are split configurable.