Date: Thu, 01 Jun 2017 09:45:14 +0200 From: Harry Schmalzbauer <freebsd@omnilan.de> To: Vincenzo Maffione <v.maffione@gmail.com> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: ovs-netmap forgotten? Message-ID: <592FC60A.1030308@omnilan.de> In-Reply-To: <CA%2B_eA9i5ZJuz34WmnHfovtgX5o8a=yzpe18L8Qeoai%2B7wf4k6Q@mail.gmail.com> References: <5926FFDB.7040900@omnilan.de> <592F20A0.4020702@omnilan.de> <CA%2B_eA9i5ZJuz34WmnHfovtgX5o8a=yzpe18L8Qeoai%2B7wf4k6Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?592FC60A.1030308>