Moritz Borcherding

Yup it's lock contention. Specifically on the Mutex around the InternalAssociation struct. Occupied time in readloop measures time used to process an SACK and in writeloop it's gathering packets to...

Ok so my suspicion was right. Pulling the marshalling our from under the lock reduces the time the mutex is locked in total drastically...but... Even if we trick tokio into...

## TLDR for this whole issue: 1. The lock around AssociationInternal is contended by the write and read loop 2. If one of the loops is doing too much work...

Even before the changes I could get ~70MB/s in release mode, but the changes I did to get to 95 where pretty small, I'd guess there is even more potential...

The three PRs combined have this effect for me: ### Current master ``` Throughput: 58522755 Bytes/s, 893 pkts, 893 loops Send 89902 pkts Throughput: 60030060 Bytes/s, 916 pkts, 916 loops...

Will do! Order of merging shouldn't matter they should be independent. But hold off from merging, I have one more idea on the write_loop behaviour I want to try.

Ok, changelogs have been done, my idea didn't work out, so you can merge if you want to

Definitely should do that. I have some ideas for that as well (and prototyping shows it increases throughput even more) but I wanted to get these PRs merged before starting...

I am a bit lost here to be honest. If I use the optimized sctp marshalling the performance just tanks on my linux PC and I cannot figure out why....

This is somewhat consistent with what I see on my machine though my spikes are much rarer. I am on a Ryzen 3800. Does Tokio employe different scheduling depending on...