Date: Fri, 14 Oct 2016 15:38:01 +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: <5800DFB9.5030102@omnilan.de> In-Reply-To: <CA%2B_eA9jC0P=HHMwouqQuHjx92fG06ti6cpe4eD6QV4afpPv9%2BQ@mail.gmail.com> References: <58009EB4.30708@omnilan.de> <CA%2B_eA9jC0P=HHMwouqQuHjx92fG06ti6cpe4eD6QV4afpPv9%2BQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bezüglich Vincenzo Maffione's Nachricht vom 14.10.2016 15:08 (localtime): > Hi, > > Thanks for your feedback. > … >> Accidentally I found out that 'vale-ctl -n testif0' creates a artificial >> interface, which is reported by ifconfig(8): >> testif0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 1500 >> options=80000<LINKSTATE> >> ether 00:be:eb:8d:f8:00 >> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> >> >> But I can't assign a IP address: 'ifconfig testif0 203.0.113.1/24' >> ifconfig: ioctl (SIOCAIFADDR): Invalid argument >> >> I guess couldn't geti the picture of the netmap(4) world yet. >> Probably, testif0 is available only in netmap(4) world, not in "host >> world". >> I'm assuming, because I found vale-ctl(-8)s "-h" switch. >> > > Yes, those are the "persistent" VALE ports. They are a recent feature, and > probably you don't need to use them if you are going to play with Virtual > Machines and jails (see below). Hello Vincenzo, thank you very much for your help!!! … >> Now my question: >> >> How can I plug a jail's or vmm's artificial interface to a VALE virtual >> switch, bridging frames to real-world via physical interfaces? >> (the latter part should work with vale-ctl -h vale0:em1, but what >> interface to use for jail(8) vnet.interface and how to create/attach?) >> > > If you use bhyve/vmm, you can attach the VM TAP interface to the VALE > switch, as you would do for "em1". Regarding jails, I don't know exactly > how networking works there, but I guess epair(4) interface (or similar) are > used. If this is the case, then you would have one end of the epair only > visible in the jail, and the other end only visible in the "host"; then you 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. 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. > could attach the host end to a VALE switch again with "vale-ctl -a". > Unfortunately, the performance you would get in any case is not great, > because TAP and epair interface do not have netmap "native support". > Moreover, when using bhyve, you have to pay the cost of the emulation of > the vtnet device, since each packet passes through this device (other than > passing across netmap). I understand, thanks. In fact, I expected that at first hand, but have had some oddities with if_bridge(4) some years ago, so I thought I'd better try something new ;-) Can I expect any resource savings over if_bridge(4)? I guess if so, the ammount isn't relevant considering the whole bhyve scenarium. > However, consider the following: a consistent netmap update is going to > happen in FreeBSD-CURRENT, in short. This is going to align the netmap code > which is now in FreeBSD to the code on the official github repository ( > 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… :-( Is it likely that there will a MFC happen? Or will it be a exclusive 12.0 feature? If ptnetmap will be MFCd I'll definitely give it a try next summer and stay with 11.0 for my replacement machines for now. Otherwise I'm unsure… best, -Harry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5800DFB9.5030102>