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
>> But I can't assign a IP address: 'ifconfig testif0'
>> 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 (
> 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:

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…


_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to