On Mon, Apr 27, 2015 at 04:30:35PM +0200, Jan Kiszka wrote:
> Am 2015-04-27 um 15:01 schrieb Stefan Hajnoczi:
> > On Mon, Apr 27, 2015 at 1:55 PM, Jan Kiszka wrote:
> >> Am 2015-04-27 um 14:35 schrieb Jan Kiszka:
> >>> Am 2015-04-27 um 12:17 schrieb Stefan Hajnoczi:
> On Sun, Apr 26, 2015 at
Am 2015-04-27 um 16:36 schrieb Luke Gorrie:
> On 27 April 2015 at 16:30, Jan Kiszka wrote:
>
>> Today, we have posted interrupts to avoid the vm-exit on the target CPU,
>> but there is nothing yet (to my best knowledge) to avoid the exit on the
>> sender side (unless we ignore security). That's t
On 27 April 2015 at 16:30, Jan Kiszka wrote:
> Today, we have posted interrupts to avoid the vm-exit on the target CPU,
> but there is nothing yet (to my best knowledge) to avoid the exit on the
> sender side (unless we ignore security). That's the same problem with
> intra-guest IPIs, BTW.
>
> F
Am 2015-04-27 um 15:01 schrieb Stefan Hajnoczi:
> On Mon, Apr 27, 2015 at 1:55 PM, Jan Kiszka wrote:
>> Am 2015-04-27 um 14:35 schrieb Jan Kiszka:
>>> Am 2015-04-27 um 12:17 schrieb Stefan Hajnoczi:
On Sun, Apr 26, 2015 at 2:24 PM, Luke Gorrie wrote:
> On 24 April 2015 at 15:22, Stefan H
On Mon, Apr 27, 2015 at 02:35:19PM +0200, Jan Kiszka wrote:
> Am 2015-04-27 um 12:17 schrieb Stefan Hajnoczi:
> > On Sun, Apr 26, 2015 at 2:24 PM, Luke Gorrie wrote:
> >> On 24 April 2015 at 15:22, Stefan Hajnoczi wrote:
> >>>
> >>> The motivation for making VM-to-VM fast is that while software
>
On Mon, Apr 27, 2015 at 02:01:05PM +0100, Stefan Hajnoczi wrote:
> A hardware solution would be some kind of inter-guest interrupt
> injection. I don't know VMX well enough to know whether that is
> possible on Intel CPUs.
It is: http://www.mulix.org/pubs/eli/eli.pdf.
(And there's hardware comi
Am 2015-04-27 um 12:17 schrieb Stefan Hajnoczi:
> On Sun, Apr 26, 2015 at 2:24 PM, Luke Gorrie wrote:
>> On 24 April 2015 at 15:22, Stefan Hajnoczi wrote:
>>>
>>> The motivation for making VM-to-VM fast is that while software
>>> switches on the host are efficient today (thanks to vhost-user), th
On Mon, Apr 27, 2015 at 1:55 PM, Jan Kiszka wrote:
> Am 2015-04-27 um 14:35 schrieb Jan Kiszka:
>> Am 2015-04-27 um 12:17 schrieb Stefan Hajnoczi:
>>> On Sun, Apr 26, 2015 at 2:24 PM, Luke Gorrie wrote:
On 24 April 2015 at 15:22, Stefan Hajnoczi wrote:
>
> The motivation for making
On Mon, Apr 27, 2015 at 1:35 PM, Jan Kiszka wrote:
> Am 2015-04-27 um 12:17 schrieb Stefan Hajnoczi:
>> On Sun, Apr 26, 2015 at 2:24 PM, Luke Gorrie wrote:
>>> On 24 April 2015 at 15:22, Stefan Hajnoczi wrote:
The motivation for making VM-to-VM fast is that while software
switches
Am 2015-04-27 um 14:35 schrieb Jan Kiszka:
> Am 2015-04-27 um 12:17 schrieb Stefan Hajnoczi:
>> On Sun, Apr 26, 2015 at 2:24 PM, Luke Gorrie wrote:
>>> On 24 April 2015 at 15:22, Stefan Hajnoczi wrote:
The motivation for making VM-to-VM fast is that while software
switches on the h
On Mon, Apr 27, 2015 at 11:17:44AM +0100, Stefan Hajnoczi wrote:
> On Sun, Apr 26, 2015 at 2:24 PM, Luke Gorrie wrote:
> > On 24 April 2015 at 15:22, Stefan Hajnoczi wrote:
> >>
> >> The motivation for making VM-to-VM fast is that while software
> >> switches on the host are efficient today (than
On Sun, Apr 26, 2015 at 2:24 PM, Luke Gorrie wrote:
> On 24 April 2015 at 15:22, Stefan Hajnoczi wrote:
>>
>> 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
On 24 April 2015 at 15:22, Stefan Hajnoczi wrote:
> 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.
>
I see. This sounds like a noble goal indeed. I
On Fri, Apr 24, 2015 at 2:10 PM, Luke Gorrie wrote:
> On 24 April 2015 at 14:17, Luke Gorrie wrote:
>>
>> For what it is worth, I think
>
>
> Erm, sorry about ranting with my pre-existing ideas without having examined
> the proposed specification in detail.
My experience with DPDK and SDN/NFV is
On Fri, Apr 24, 2015 at 1:17 PM, Luke Gorrie wrote:
> On 24 April 2015 at 11:47, Stefan Hajnoczi wrote:
>>
>> My concern is the overhead of the vhost_net component copying
>> descriptors between NICs.
>
>
> I see. So you would not have to reserve CPU resources for vswitches. Instead
> you would g
On 24 April 2015 at 14:17, Luke Gorrie wrote:
> For what it is worth, I think
>
Erm, sorry about ranting with my pre-existing ideas without having examined
the proposed specification in detail.
I have a long backlog of things that I have been meaning to discuss with
the Virtio-net community but
On 24 April 2015 at 11:47, Stefan Hajnoczi wrote:
> > Incidentally, we also did a pile of work last year on zero-copy NIC->VM
> > transfers and discovered a lot of interesting problems and edge cases
> where
> > Virtio-net spec and/or drivers are hard to match up with common NICs.
> Happy
> > to
On 24 April 2015 at 11:47, Stefan Hajnoczi wrote:
> My concern is the overhead of the vhost_net component copying
> descriptors between NICs.
I see. So you would not have to reserve CPU resources for vswitches.
Instead you would give all cores to the VMs and they would pay for their
own network
On Fri, Apr 24, 2015 at 10:47 AM, Stefan Hajnoczi wrote:
> At this level it's compared to vhost-user, but it's not programmable
> in userspace!
s/compared/comparable/
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://list
On Fri, Apr 24, 2015 at 9:12 AM, Luke Gorrie 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 l
On 24/04/2015 10:12, Luke Gorrie wrote:
>
> I think this approach could be fruitful in bringing virtio-net to
> VM-to-VM networking use cases. Unless virtio-net is extended for this
> use case, I'm afraid DPDK and OpenDataPlane communities might steer
> clear of VIRTIO.
>
>
>
Hi Stefan,
Great topic. I am also extremely interested in helping Virtio-net become
the standard for the networking industry (the universe of DPDK, etc).
On 22 April 2015 at 19:01, Stefan Hajnoczi wrote:
> [It may be necessary to remove virtio-...@lists.oasis-open.org from CC
> if you are a non
On Wed, 22 Apr 2015 19:00:52 +0100
Stefan Hajnoczi wrote:
> On Wed, Apr 22, 2015 at 6:46 PM, Cornelia Huck
> wrote:
> > On Wed, 22 Apr 2015 18:01:38 +0100
> > Stefan Hajnoczi wrote:
> >> virtio-net VM-to-VM extensions
> >> --
> >> A few extensions to virtio-net are
On Wed, Apr 22, 2015 at 6:46 PM, Cornelia Huck wrote:
> On Wed, 22 Apr 2015 18:01:38 +0100
> Stefan Hajnoczi wrote:
>
>> [It may be necessary to remove virtio-...@lists.oasis-open.org from CC
>> if you are a non-TC member.]
>>
>> Hi,
>> Some modern networking applications bypass the kernel networ
On Wed, 22 Apr 2015 18:01:38 +0100
Stefan Hajnoczi wrote:
> [It may be necessary to remove virtio-...@lists.oasis-open.org from CC
> if you are a non-TC member.]
>
> Hi,
> Some modern networking applications bypass the kernel network stack so
> that rx/tx rings and DMA buffers can be directly ma
[It may be necessary to remove virtio-...@lists.oasis-open.org from CC
if you are a non-TC member.]
Hi,
Some modern networking applications bypass the kernel network stack so
that rx/tx rings and DMA buffers can be directly mapped. This is
typical in DPDK applications where virtio-net currently i
26 matches
Mail list logo
