Hi Harry, Following some examples in the presentation you linked, Im rather suprised that i'm apparently already utilizing the ng subsystem on some of my machines (ngctl list lists entries and a couple of hooks as well).
Ill put a rig together for some playing around with the netgraph subsystem, very interesting! Thank you (again) for your elaboration :) Kind regards, Ruben On 26/02/2018 13:13, Harry Schmalzbauer wrote: > Bezüglich Ruben's Nachricht vom 26.02.2018 11:34 (localtime): >> On 26/02/2018 10:56, Harry Schmalzbauer wrote: > … >>> Another, personally very significant, reason is that you'll get a >>> superfluous host interface for each if_bridge(4), which makes the output >>> of plain ifconfig(8) kind of unreadable. > … >> By superflous host interfaces, do you mean the tap interfaces configured >> for each vm together with the bridge interfaces they are "bundled" in? > Additionally to the if_tap(4) ethernet host interfaces, you also get > if_bridge(4) ethernet interfaces, named bridgeX if I remember correctly. > The if_bridge(4) host interface is for control purposes only on a VM-SDN > host – at least with my setups. I never needed to make use of IP > numbered bridges. And I don't need to utilize any if_bridge(4) features > like STP, so I consider the bridgeX host interfaces as superfluous in > the VM-SDN use case. > > I'd call the if_tap(4) host interfaces likewise superfluous – you would > only need the corresponding character devices – but that's been > implemented long before the need for SDN setups, so it is like it is. > And using ng_bridge(4) instead of if_bridge(4) doesn't change the need > for if_tap(4). Only with vale(4) switches, bhyve(8) was able to provide > virtio-net connection wihtout "spamming" the host's ethernet interface > list (no tapX, no bridgeX). > > >> Overall I'm very happy with my bhyve setups atm. If there are any >> speed-/administrative-advantages that come with bridge_ng however, I'm >> very interested in switching to such a setup (or at least play with it). >> I'm running my vm's without any helper project so I'm flexible enough to >> do some fiddling :P >> >> Do you know of any documentation on using bridge_ng together with bhyve? >> My search-engines don't turn up much Im affraid and I haven't stumbled >> on it before. > Unfortunately it's not too easy to get started with netgraph. > Besides numerous man pages for the different nodes (ng_bridge(4) e.g.), > I only know the following source for a good overview: > http://www.netbsd.org/gallery/presentations/ast/2012_AsiaBSDCon/Tutorial_NETGRAPH.pdf > > One convenience disadvantage with ng_bridge(4) is that you have to > assign MACs manually, while if_bridge(4) does that itself (adjustable by > sysctl net.link.bridge.inherit_mac). > And you need to script all setups yourself. Almost all of my setups > seem to be awkward enough that I always had to do some local scripting, > so that wasn't really a disadvantage for me. > > If you're happy with your setup, I don't think you gain anything from > switching to ng_bridge(4), besides learning to control netgraph(4) > (which is very desirable imho). > I haven't had time left to do useful benchmarking regarding ng_bridge(4) > vs. if_bridge(4). I even don't know if netgraph nodes are still limited > to single threads. But rough load comparings on a IvyBride machine > showed similar resource usage for both bridges, both easy capable of > 1GbE saturation with small frames (while I remember one run with > ng_bridge(4) and if_vmnet(4), which couldn't deliver 1GbE speed, and I > wanted to falsify for vmnet/tap difference... just ran out of time :-( ). > > -harry _______________________________________________ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
