Bezüglich Vincenzo Maffione's Nachricht vom 15.10.2016 09:32 (localtime): > 2016-10-14 15:38 GMT+02:00 Harry Schmalzbauer <free...@omnilan.de>:
… >> I'm familar with epair(4), but not with tap(4). >> I don't understand the man page for tap, perhaps I should read pty(4)… >> But I guess I don't have to know the details of tap(4), since you >> confirmed that it can be connected to VALE. >> > > It's not necessary to understand the details. However, a TAP device is > conceptually similar to the two ends of an epair, with the difference that > in the TAP a network interface (e.g. tap0) is conecptually "connected" > back-to-back to a file descriptor. The file descriptor is written/read by > the hypervisor (to inject/intercept packets to/from the network stack), > while the tap0 interface can be attached to if_bridge. Hi Vincenzo, thanks for your explanation! >> >> So one could summarize: >> VALE (as part of netmap(4)) can act as a if_bridge(4) replacement in >> FreeBSD-10/11, keeping everything else involved untouched. >> Please correct me if I'm wrong. >> > > For simple cases yes. if_bridge may have features that are not supported by > netmap (i.e. configure ports as VLAN access ports). Moreover, if_bridge has > a interface (br0), whereas VALE bridges doesn't. Again, thank you for your time! (R)STP comes to my mind (which I don't need any more). And I'm not sure if VALE really lacks that, but I guess it wouldn't match VALEs philosophy/design at all… … >>> https://github.com/luigirizzo/netmap). Among the new features, there is >> a >>> new solution for bhyve networking, which will let you attach your bhyve >> VMs >>> directly to a VALE switch, without paying additional overheads related to >>> TAPs, epairs, and vtnet emulation. You can find additional information, >>> code and performance numbers here: >>> https://wiki.freebsd.org/SummerOfCode2016/PtnetDriverAndDeviceModel. >> >> Thanks for that hint! >> I guess it's about ptnetmap(4)? I read papers but haven't considered it >> could be production-ready for FreeBSD in the near future. >> It's extremely interesting and I'd love to be eraly adopter, but my >> (ESXi) setups are currently doing well and I don't have spare time or >> any business project to try out… :-( >> > > Yes, it's ptnetmap. However, bhyve is going to have support for VALE ports > anyway (even without ptnetmap), as QEMU already does, so at least you will > be able to replace TAPs with VALE ports (while still using vtnet devices > for the VM). Oic, I wasn't aware that there will be a VALE-vtnet direct path! That is really great news :-) And a big achievment for guests preferring "standard" drivers, ptnetmap could limit the guest OS choice I guess. For now, I'm happy having been in touch with netmap(4) – at least with a very little fraction of natmap – but I'll stay the legacy way utilizing if_bridge(4) and see if there are still oddities and try to find some time to track them down (involving LACP, VLANs, Jumbo-Frames and IPv6 – that was the problematic constellation) Since I have extra PHYs, I can do PCIe-passthrough like before (with ESXi) for some special guests. I'm looking forward to find out how this works with bhyve! Best, -Harry _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
