From owner-freebsd-stable@freebsd.org Sat Oct 15 09:42:10 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D212CC12D61; Sat, 15 Oct 2016 09:42:10 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82FFF78F; Sat, 15 Oct 2016 09:42:09 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id u9F9g7jn092749; Sat, 15 Oct 2016 11:42:07 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 94F7C197; Sat, 15 Oct 2016 11:42:06 +0200 (CEST) Message-ID: <5801F9EE.1000407@omnilan.de> Date: Sat, 15 Oct 2016 11:42:06 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: FreeBSD Net , FreeBSD Stable , Luigi Rizzo Subject: Re: vale-ctl(-8), ifconfig(8), SIOCAIFADDR: Invalid argument [utilizing netmap(4) providing virtual switches+interfaces to BHyVe] References: <58009EB4.30708@omnilan.de> <5800DFB9.5030102@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Sat, 15 Oct 2016 11:42:07 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 09:42:10 -0000 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… … >>> 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