Generally people get more excited any time a major release of anything comes out. But FWIW HN has always had favorable front paging for anything related to FreeBSD and OpenBSD.
When this settles down, I look forward to all of jail/iojail, Sylve, Bastille, Bhyve documenting this in a mutually consistent manner. As it stands, I have managed to completely knot my brain over the abstractions, what is happening. It's me, not the systems, but I think there is a little bit of "meh, I understand it, so it must be obvious to anyone smart" going on, and alas, I am not smart, and I get confused easily.
I'm in bastille atm, but have been in all of them and TrueNAS core. and libvirt over on the other unix.
Bhyve bridges are inefficient: every packet traverses NIC → CPU → bridge → VM, adding unnecessary copies that kill throughput. Switching to SR-IOV eliminated that overhead and I saturated the 10 GbE link.
I do not see how that follows. Memory bandwidth is measured in the hundreds of Gb/s. You can issue tens of unnecessary full memory copies before you bottleneck at a paltry 10 Gb/s.
It is much more likely there is something else terribly wrong in a network stack if it can not even drive a measly 10 Gb/s.
People found this worked in the past and it gets copied around. There is no reason to disable some of this. Bridge will automatically disable LRO and find the common set of other offloads. TSO is not useful for a bridged guest.
Did anything special or new happened on FreeBSD land?
Back to FreeBSD: Part 1 (hypha.pub) https://news.ycombinator.com/item?id=47108989
Linuxulator on FreeBSD Feels Like Magic (hayzam.com) https://news.ycombinator.com/item?id=47113527
I'm in bastille atm, but have been in all of them and TrueNAS core. and libvirt over on the other unix.
It is much more likely there is something else terribly wrong in a network stack if it can not even drive a measly 10 Gb/s.
Whys the author disabling tso and lro? Whats the motivation?
I'm not familiar with the other flags.