https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287229
--- Comment #15 from Lucas Aubard <lucas.aub...@irisa.fr> --- Sorry for the late reply; I was running more tests based on the information you provided. @Timo Thanks for the FreeBSD operating description when processing fragments. I confirm that by commenting vm.kmem_size and vm.kmem_size_max in box bento/freebsd-14.1, the net.inet.ip.maxfragbucketsize value is now set to 7 after a reboot. I also confirm observing the same reassembly across the runs for all our test cases. Thanks a lot for pointing out these kernel parameters. @Michael Actually, I did not modify nor check the default VM settings since I observed this behavior with different FreeBSD boxes. For example, the official (?) FreeBSD box freebsd/FreeBSD-14.1-STABLE has only one parameter specified in /boot/loader.conf: autoboot_delay="-1". I am also able to observe a net.inet.ip.maxfragbucketsize value of 1 with this box (that has thus not the vm.kmem_size and vm.kmem_size_max specified) in the case I run multiple VMs in parallel. From @Rodney's comment, I guess the memory dynamically allocated to the FreeBSD VM is low because multiple VMs are running, leading to a net.inet.ip.maxfragbucketsize value of 1. With the freebsd/FreeBSD-14.1-STABLE box, by manually allocating memory to the Vagrantfile: - 512Mb gives net.inet.ip.maxfragbucketsize = 1. For 40 test cases tested in parallel, I observed many reassembly inconsistencies. - 1024Mb gives net.inet.ip.maxfragbucketsize = 3. For 40 test cases tested in parallel, I observed 1 test case reassembly inconsistency (out of the 10,362 test cases). - 2048Mb gives net.inet.ip.maxfragbucketsize = 7. For 40 test cases tested in parallel, I did not observe any reassembly inconsistency. So, I should force the allocated memory to the FreeBSD box to 2048Mb when running my tests in parallel to avoid observing reassembly inconsistencies. -- You are receiving this mail because: You are on the CC list for the bug.
