Date: Sat, 15 Oct 2016 11:42:06 +0200 From: Harry Schmalzbauer <freebsd@omnilan.de> To: Vincenzo Maffione <v.maffione@gmail.com> Cc: FreeBSD Net <freebsd-net@freebsd.org>, FreeBSD Stable <freebsd-stable@freebsd.org>, Luigi Rizzo <rizzo.unipi@gmail.com> Subject: Re: vale-ctl(-8), ifconfig(8), SIOCAIFADDR: Invalid argument [utilizing netmap(4) providing virtual switches+interfaces to BHyVe] Message-ID: <5801F9EE.1000407@omnilan.de> In-Reply-To: <CA%2B_eA9jL2kcYEzAeEkcymsqzs-a4j06mwXsX4QykqPWv1agPjw@mail.gmail.com> References: <58009EB4.30708@omnilan.de> <CA%2B_eA9jC0P=HHMwouqQuHjx92fG06ti6cpe4eD6QV4afpPv9%2BQ@mail.gmail.com> <5800DFB9.5030102@omnilan.de> <CA%2B_eA9jL2kcYEzAeEkcymsqzs-a4j06mwXsX4QykqPWv1agPjw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bezüglich Vincenzo Maffione's Nachricht vom 15.10.2016 09:32 (localtime): > 2016-10-14 15:38 GMT+02:00 Harry Schmalzbauer <freebsd@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5801F9EE.1000407>