[SCTP] Optimize sctp packet marshalling

[KillingSpark]

As discussed in #360 the marshalling code has become a bottle neck in high bandwidth sending situations. I found two places that had a big effect on the performance, the hot path for this situation is marshalling packets with exactly one data chunk in them.

After this PR the marshalling is largely dominated by the CRC32 calculation which is... not easy to speed up.

[codecov]

Codecov Report

Base: 59.99% // Head: 59.99% // Decreases project coverage by -0.00% ⚠️

Coverage data is based on head (1035ae9) compared to base (0f98498).
Patch coverage: 90.00% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #364      +/-   ##
==========================================
- Coverage   59.99%   59.99%   -0.01%     
==========================================
  Files         504      504              
  Lines       48073    48068       -5     
  Branches    12517    12517              
==========================================
- Hits        28839    28836       -3     
+ Misses      10011    10010       -1     
+ Partials     9223     9222       -1     

Impacted Files	Coverage Δ
sctp/src/packet.rs	62.92% <87.50%> (-1.60%)	⬇️
sctp/src/chunk/chunk_payload_data.rs	81.19% <100.00%> (ø)
sctp/src/util.rs	100.00% <100.00%> (ø)
turn/src/client/transaction.rs	63.39% <0.00%> (-1.31%)	⬇️
util/src/conn/conn_udp_listener.rs	64.10% <0.00%> (-1.29%)	⬇️
sctp/src/association/association_test.rs	58.87% <0.00%> (-0.09%)	⬇️
ice/src/agent/agent_internal.rs	69.04% <0.00%> (ø)
ice/src/agent/agent_vnet_test.rs	69.90% <0.00%> (ø)
interceptor/src/stats/interceptor.rs	79.18% <0.00%> (+0.47%)	⬆️
ice/src/udp_mux/udp_mux_test.rs	63.35% <0.00%> (+0.62%)	⬆️
... and 3 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[melekes]

👍

[KillingSpark]

Just an FYI, I implemented a faster crc32 algorithm on the merged branch in my repo just as an PoC that make the crc calucations basically disappear in the profile and increases throughput even more. I'll try to port this to the crc crate to benefit the whole ecosystem. If they don't want it I'll make an PR to at least let this crate benefit :)

[melekes]

why do we need 16 bytes then? if max is 4

[melekes]

actually it's a bit dangerous in a sense that PADDING_MULTIPLE may change and this will throw a runtime error. why can't we do [0u8; padding_needed]? because it's slower?

[KillingSpark]

why can't we do [0u8; padding_needed]

Because rust doesn't allow dynamically sized arrays on the stack right?

actually it's a bit dangerous in a sense that PADDING_MULTIPLE may change and this will throw a runtime error

This is a good point, if unlikely since the RFC for SCTP will probably never change in this regard. I can just use PADDING_MULTIPLE as the size though. since padding_needed is guaranteed to be < PADDING_MULTIPLE