[kronosnet/kronosnet] 3fb016: [host] fix defrag buffers reclaim logic

Branch: refs/heads/netload-fixes Home: https://github.com/kronosnet/kronosnet Commit: 3fb0166ebd14e37a2fb9fe7aeae53d09e0e66b74 https://github.com/kronosnet/kronosnet/commit/3fb0166ebd14e37a2fb9fe7aeae53… Author: Fabio M. Di Nitto <fdinitto(a)redhat.com> Date: 2019-10-15 (Tue, 15 Oct 2019) Changed paths: M libknet/host.c Log Message: ----------- [host] fix defrag buffers reclaim logic The problem: - let's assume a 2 nodes (A and B) cluster setup - node A sends fragmented packets to node B and there is packet loss on the network. - node B receives all those fragments and attempts to reassemble them. - node A sends packet seq_num X in Y fragments. - node B receives only part of the fragments and stores them in a defrag buf. - packet loss stops. - node A continues to send packets and a seq_num roll-over takes place. - node A sends a new packet seq_num X in Y fragments. - node B gets confused here because the parts of the old packet seq_num X are still stored and the buffer has not been reclaimed. - node B continues to rebuild packet seq_num X with old stale data and new data from after the roll-over. - node B completes reassembling the packet and delivers junk to the application. The solution: Add a much stronger buffer reclaim logic that will apply on each received packet and not only when defrag buffers are needed, as there might be a mix of fragmented and not fragmented packets in-flight. The new logic creates a window of N packets that can be handled at the same time (based on the number of buffers) and clear everything else. Fixes https://github.com/kronosnet/kronosnet/issues/261 Signed-off-by: Fabio M. Di Nitto <fdinitto(a)redhat.com> Commit: 8b2863b392d275ea50fa19e8e8bebe40a6134707 https://github.com/kronosnet/kronosnet/commit/8b2863b392d275ea50fa19e8e8beb… Author: Fabio M. Di Nitto <fdinitto(a)redhat.com> Date: 2019-10-15 (Tue, 15 Oct 2019) Changed paths: M libknet/threads_rx.c Log Message: ----------- [rx] copy data into the defrag buffer only if we know the size of the frame Signed-off-by: Fabio M. Di Nitto <fdinitto(a)redhat.com> Commit: d39c189900ef1a5647c7264e799f793ab9fd93e2 https://github.com/kronosnet/kronosnet/commit/d39c189900ef1a5647c7264e799f7… Author: Fabio M. Di Nitto <fdinitto(a)redhat.com> Date: 2019-10-15 (Tue, 15 Oct 2019) Changed paths: M libknet/tests/knet_bench.c Log Message: ----------- [test] add ability to knet_bench to specify a fixed packet size for perf test Signed-off-by: Fabio M. Di Nitto <fdinitto(a)redhat.com> Commit: 34c08ae7e7903d79f06569b4f506a00c15af0238 https://github.com/kronosnet/kronosnet/commit/34c08ae7e7903d79f06569b4f506a… Author: Fabio M. Di Nitto <fdinitto(a)redhat.com> Date: 2019-10-15 (Tue, 15 Oct 2019) Changed paths: M libknet/threads_pmtud.c Log Message: ----------- [PMTUd] invalidate MTU for a link if the value is lower than minimum Under heavy network load and packet loss, calculated MTU can be too small. In that case we need to invalidate the link mtu, that would remove the link from the rotation (and traffic) and would give PMTUd time to get the right MTU in the next round. Signed-off-by: Fabio M. Di Nitto <fdinitto(a)redhat.com> Compare: https://github.com/kronosnet/kronosnet/compare/e2af2fce11a7...34c08ae7e790