From owner-freebsd-net@freebsd.org Thu Jun 1 07:45:19 2017 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 D82A5BEE39C for ; Thu, 1 Jun 2017 07:45:19 +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 86E866A0A3 for ; Thu, 1 Jun 2017 07:45:19 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v517jFgU075722; Thu, 1 Jun 2017 09:45:15 +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 47646E22; Thu, 1 Jun 2017 09:45:15 +0200 (CEST) Message-ID: <592FC60A.1030308@omnilan.de> Date: Thu, 01 Jun 2017 09:45:14 +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 Subject: Re: ovs-netmap forgotten? References: <5926FFDB.7040900@omnilan.de> <592F20A0.4020702@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]); Thu, 01 Jun 2017 09:45:15 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) 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: Thu, 01 Jun 2017 07:45:19 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 01.06.2017 00:39 (localtime): > Hi Harry, > OVS integration with netmap is very patchy and Linux only. Most > importantly, it is not the right way to go, for a number of reasons. > The real solution would be to integrate netmap into OVS would be to > follow the DPDK-OVS approach: this means implementing the switching > logic completely in userspace, in this case using the netmap API. This > has not been implemented nor sketched so far. > > `vale-ctl -n valeXXX:YYY` just creates a persistent VALE port (YYY) > attached to the VALE switch XXX. > There is no difference with an ephemeral VALE port, apart for the fact > that the persistent one is visible with ifconfig. > > It does not really make sense to attach a VLAN interface to VALE, since > the VLAN driver does not have netmap support, so you lose all the > advantage of using netmap and VALE. > In your case the best solution I see is to write a custom netmap > application that forwards the packets between a netmap-supported NIC and > one or more VMs, doing the VLAN stripping in software. Thanks again, Vincenzo, for your highly appreciated support! I can only concur to your proposed solution. Problem is, I don't speak any programmin language well (besides sh maybe) and have abosuletely no budget/time to do any work out on my C skills (which I'd love to do) ;-) So ovs-netmap wasn't the right direction, but the difference between em0+if_brdige+vmnet|virtio-net+vtnet and vale:em0|vale:guest+vtnet is noticable. I haven't done any measuring, but just performing typical admin jobs via cli (ssh into the bhyve-guest, whith resorces via NFS (v4)) behave completely different – human-noticable much more snappy in the vale:guest case! I don't think this enormous efficiency advantge is soleley caused by em0-netmap/ring connection; More important, in the vale:em0|vale:guest+vtnet case, I gain excellent inter-vm efficiency (and much higher attainable performance of course, which is not crucial at the moment; but efficiency is!). Now replacing vale:em0 by vale:vlan0 will surely destroy one big efficiency advantage, but I still benefit from excellent inter-vm efficiency and most likely some small efficiency advantage left over the if_bridge picture. Also, ptnet is a very interisting area of optimization which is easy to explore with the vale:vlan scenario. In another post I described that the vale:vlan path doesn't work, while vale:em0 (the parent) with everything else untouched does work. Dou you think it's possible to fix the vale:vlan coupling without netmap experts setting up a test environment? Thanks, -harry