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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[email protected]"
