search for: snabbswitch

...node so that you can predict > what network performance will be available. The motivation for making VM-to-VM fast is that while software switches on the host are efficient today (thanks to vhost-user), there is no efficient solution if the software switch is a VM. Have you had requests to run SnabbSwitch in a VM instead of on the host? For example, if someone wants to deploy it in a cloud environment they will not be allowed to run arbitrary software on the host. Stefan

...node so that you can predict > what network performance will be available. The motivation for making VM-to-VM fast is that while software switches on the host are efficient today (thanks to vhost-user), there is no efficient solution if the software switch is a VM. Have you had requests to run SnabbSwitch in a VM instead of on the host? For example, if someone wants to deploy it in a cloud environment they will not be allowed to run arbitrary software on the host. Stefan

...in question is setup- > time only. Agreed, we don't see dependency on kernel driver is a problem. mdev based vhost backend (this patch set) is independent with vhost-user extension patch set. In fact, there're a few vhost-user providers, DPDK librte_vhost is one of them. FD.IO/VPP and snabbswitch have their own vhost-user providers. So I can't agree on vhost-user extension patch depends on DPDK backend. But anyway, that's the topic of another mail thread. > > As others said, we do not need to go overeboard. A couple of small vendor- > specific quirks in qemu isn't a b...

...ser). But that is just a hunch and I suppose the first step would be a prototype to check the performance anyway. For what it is worth here is my view of networking performance on x86 in the Haswell+ era: https://groups.google.com/forum/#!topic/snabb-devel/aez4pEnd4ow Have you had requests to run SnabbSwitch in a VM instead of on the > host? This is not something we have discussed. I can say that I am not satisfied with our installation process on the host. I want this to be trivially easy, but it is not. On the one hand we make some parts easy: we only require one executable file (~1.5MB) and i...

...u short narrow it for networking use cases only. Shared memory ? la ivshmem provides other features (see (A) again). > > vhost-user is superior, and it is superior because it has been > designed > from the get-go through cooperation of all interested parties (namely > QEMU and snabbswitch). It is not an argument. vhost-user is a specific case. Best regards, Vincent

On Fri, Apr 24, 2015 at 9:12 AM, Luke Gorrie <luke at snabb.co> wrote: > - How fast would the new design likely be? This proposal eliminates two things in the path: 1. Compared to vhost_net, it bypasses the host tun driver and network stack, replacing it with direct vhost_net <-> vhost_net data transfer. At this level it's compared to vhost-user, but it's not programmable

On Fri, Apr 24, 2015 at 9:12 AM, Luke Gorrie <luke at snabb.co> wrote: > - How fast would the new design likely be? This proposal eliminates two things in the path: 1. Compared to vhost_net, it bypasses the host tun driver and network stack, replacing it with direct vhost_net <-> vhost_net data transfer. At this level it's compared to vhost-user, but it's not programmable

Some dropped quoted text restored. Vincent JARDIN <vincent.jardin at 6wind.com> writes: > Markus, > > see inline (I am not on all mailing list, please, keep the cc list). > >> Sure! The reasons for my dislike range from practical to >> philosophical. >> >> My practical concerns include: >> >> 1. ivshmem code needs work, but has no maintainer

Some dropped quoted text restored. Vincent JARDIN <vincent.jardin at 6wind.com> writes: > Markus, > > see inline (I am not on all mailing list, please, keep the cc list). > >> Sure! The reasons for my dislike range from practical to >> philosophical. >> >> My practical concerns include: >> >> 1. ivshmem code needs work, but has no maintainer

Henning Schild <henning.schild at siemens.com> writes: > On Thu, 12 Jun 2014 08:48:04 +0200 > Markus Armbruster <armbru at redhat.com> wrote: > >> Vincent JARDIN <vincent.jardin at 6wind.com> writes: >> >> > On 10/06/2014 18:48, Henning Schild wrote:> Hi, >> >> In a first prototype i implemented a ivshmem[2] device for the >>

Henning Schild <henning.schild at siemens.com> writes: > On Thu, 12 Jun 2014 08:48:04 +0200 > Markus Armbruster <armbru at redhat.com> wrote: > >> Vincent JARDIN <vincent.jardin at 6wind.com> writes: >> >> > On 10/06/2014 18:48, Henning Schild wrote:> Hi, >> >> In a first prototype i implemented a ivshmem[2] device for the >>

> -----Original Message----- > From: Paolo Bonzini [mailto:pbonzini at redhat.com] > Sent: Tuesday, April 10, 2018 3:52 PM > To: Bie, Tiwei <tiwei.bie at intel.com>; Jason Wang <jasowang at redhat.com> > Cc: mst at redhat.com; alex.williamson at redhat.com; ddutile at redhat.com; > Duyck, Alexander H <alexander.h.duyck at intel.com>; virtio-dev at lists.oasis-