Bezüglich Vincenzo Maffione's Nachricht vom 15.10.2016 09:32 (localtime):
> 2016-10-14 15:38 GMT+02:00 Harry Schmalzbauer <>:

>> 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…

>>> 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… :-(
> 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!


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

Reply via email to