From owner-freebsd-net@freebsd.org Sun Oct 16 09:29:04 2016 Return-Path: Delivered-To: freebsd-net@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 8CF4DC12FC4; Sun, 16 Oct 2016 09:29:04 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F09F3D6; Sun, 16 Oct 2016 09:29:04 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x231.google.com with SMTP id d132so182801939oib.2; Sun, 16 Oct 2016 02:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1mzgs/x2ybum58ghVWHFPJD2QjKo7A2h1u3IUBSovDo=; b=pB2iBQ8ZDeGn7VNIE4ETQ6WWkqO8ALECyl3M5h1BFrg0hD3JcPMdB6O7S8Z9mkJGlR 5bXuF8UbGxHkbIZoABUk6ZiU2IvDsqS9tHaRRDyFpWa7TDDd+UwgHyx23rH8ADfRn4bC HJfLA5FyPcw1MZ/smsZMT5jeEkRNwCXFDNMREyJIr4a7M2Yxjiv28LlgxBh7sYG5jetj pj1O7NFs9SQL0wXWwe9ixyfte5th5hfoEVwz/M+wWyG3n9+em9L8nIaSV8N62lYxU2Gw j5wufg9myvU//59WP0rEhJWp8XLzP0HuSKmmQCuTWEhTcuwaEh4wmpALFJyabwAKLOAj Auqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1mzgs/x2ybum58ghVWHFPJD2QjKo7A2h1u3IUBSovDo=; b=mo8eYKXyySivzsiSSW+gsnBBn2cTC2Q5gbKMJWzIWNgtUIQJVsqsRQ9Oy3a3D8rMvc to/iyjUr2UhRzcQJNKyCulMZrAiPf6Hf+nU5OMfyyafX+qS7tpQoIi39dZpG5st30vYr 2ji3l9S0dFGYdByFTXVAXhM7uPEhF4gB06kRU1fiWBJZz+ZCUOwn+uHyYqQbw61mVf1+ amfpU6Ln4FqZAVOqgFEwD3R1J1X9Z3FLjl8XfkbT9pId6HbmXg8++q8ZbQ+6POLr4OnX xtv8cxb/pBOl1cPIzst64AArxN1ouRmQaY8RTR+8OLiKbrLpLRfxnfMCuA8/XQ3Rm4rz oKxw== X-Gm-Message-State: AA6/9RmvlhKd/NZmVM2EU4jqGO8A6UQd1lVXf5KPK24UAb8RpBKrO8iE7amoaGe7g1tOIs1kPqo9+SpMVmzOmQ== X-Received: by 10.202.74.79 with SMTP id x76mr13574558oia.77.1476610143656; Sun, 16 Oct 2016 02:29:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.61.52 with HTTP; Sun, 16 Oct 2016 02:29:03 -0700 (PDT) In-Reply-To: <5801F9EE.1000407@omnilan.de> References: <58009EB4.30708@omnilan.de> <5800DFB9.5030102@omnilan.de> <5801F9EE.1000407@omnilan.de> From: Vincenzo Maffione Date: Sun, 16 Oct 2016 11:29:03 +0200 Message-ID: Subject: Re: vale-ctl(-8), ifconfig(8), SIOCAIFADDR: Invalid argument [utilizing netmap(4) providing virtual switches+interfaces to BHyVe] To: Harry Schmalzbauer Cc: FreeBSD Net , FreeBSD Stable , Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 09:29:04 -0000 2016-10-15 11:42 GMT+02:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 15.10.2016 09:32 (localt= ime): > > 2016-10-14 15:38 GMT+02:00 Harry Schmalzbauer : > > =E2=80=A6 > >> 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)= =E2=80=A6 > >> 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 supporte= d > 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=E2=80=A6 > Well, VALE is a programmable switch, meaning that you can plug in a custom forwarding function (which is just a C function). The default forwarding function implements an L2 learning bridge without STP, because it is thought to be used as the preferred hypervisor virtual switch, so no L2 connectivity loops, and the STP comes with an overhead. If you really wish to have VALE with STP, you could define your own custom forwarding function that implements it. > > =E2=80=A6 > >>> https://github.com/luigirizzo/netmap). Among the new features, there > is > >> a > >>> new solution for bhyve networking, which will let you attach your bhy= ve > >> VMs > >>> directly to a VALE switch, without paying additional overheads relate= d > to > >>> TAPs, epairs, and vtnet emulation. You can find additional informatio= n, > >>> 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 i= t > >> 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=E2=80=A6 :-( > >> > > > > 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 device= s > > 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. > Yes ptnetmap is supported on QEMU and bhyve, and as a gues you can use only FreeBSD and Linux, at the moment. > > For now, I'm happy having been in touch with netmap(4) =E2=80=93 at least= with a > very little fraction of natmap =E2=80=93 but I'll stay the legacy way uti= lizing > 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 =E2= =80=93 > 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! > > No idea, but also ptnetmap is able to do that: not only you can pass-through a VALE port, but also you can pass-through a physical interface. Cheers, Vincenzo > Best, > > -Harry > --=20 Vincenzo Maffione