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.
Honestly, best thing I did was ditch all that and just read the handbook, specificially chapter 17 [1]. All of my jails are now set up manually, initially using /etc/jail.conf, and now individual jail configs in /etc/jail.conf.d/.
I still use vm-bhyve [2] for my Bhyve virtual machines, but that's been rock solid for me for years.
They have also soft-deprecated the ability to have any layer 3 addresses on member interfaces which makes it behave like a real hardware switch. The net.link.bridge.member_ifaddrs sysctl controls this behavior and it will be removed in FreeBSD 16.0-RELEASE, same as if set to zero.
I'm a little bit uncertain. This means that the bridge may have one or more L3 addresses assigned to it, but the interfaces attached to that bridge may not, right?
If that's right, how does that interact with things like Linux's veth pairs? [0] Can the half of the pair that's not a member of the bridge have an IP address?
[0] I assume something like that exists in FreeBSD-land.
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.
I think people are looking for new alternatives to tinker with. Linux is becoming new Windows and BSDs new Linux. I dunno what is Windows becoming, but it ain't good.
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.
Honestly, best thing I did was ditch all that and just read the handbook, specificially chapter 17 [1]. All of my jails are now set up manually, initially using /etc/jail.conf, and now individual jail configs in /etc/jail.conf.d/.
I still use vm-bhyve [2] for my Bhyve virtual machines, but that's been rock solid for me for years.
[1] https://docs.freebsd.org/en/books/handbook/jails/
[2] https://github.com/freebsd/vm-bhyve
From TFA:
I'm a little bit uncertain. This means that the bridge may have one or more L3 addresses assigned to it, but the interfaces attached to that bridge may not, right?
If that's right, how does that interact with things like Linux's veth pairs? [0] Can the half of the pair that's not a member of the bridge have an IP address?
[0] I assume something like that exists in FreeBSD-land.
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.
That assumes memory bandwidth is the issue, and not latency and/or CPU.
1 reply →
It would benefit from a batching mechanism.
You used the new optimized bridges on FreeBSD 15?
The bridge driver gained features (vlan filtering) not performance.
On Linux?
I for one welcome and applaud any progress on the bsd front,and this seems to be huge.
> -tso4 -tso6 -vlanhwfilter -vlanmtu -vlanhwtso -vlanhwtag -vlanhwcsum -lro
Whys the author disabling tso and lro? Whats the motivation?
I'm not familiar with the other flags.
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.
Looks like TSO does not support VLAN. Not sure about lro.
LRO because the bridge has to forward the real frames. TSO because it’s fairly useless now.
Why sudden surge of FreeBSD-related posts?
Did anything special or new happened on FreeBSD land?
I think people are looking for new alternatives to tinker with. Linux is becoming new Windows and BSDs new Linux. I dunno what is Windows becoming, but it ain't good.
> Linux is becoming new Windows and BSDs new Linux.
Can you elaborate?
1 reply →
Perhaps the initial posts spurred reader interest in FreeBSD which then spurred further posts?
FreeBSD is great - good to see it get positive "airtime."
15.0 was released a couple months ago, hence the title.
We have three (including this) FreeBSD posts in the past two days.
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
4 replies →
I was wondering the same.