On 2 August 2016 at 19:32, Michael S. Tsirkin wrote:
> I think this is adequately answered here:
> http://git.qemu.org/?p=qemu.git;a=blob;f=docs/specs/vhost-
> user.txt;hb=HEAD#l149
>
Thanks for the gentle nudge :). Indeed, it is working great with all QEMU
versions now. I see now why my patch i
Hi Michael & all,
On 4 August 2015 at 21:00, Luke Gorrie wrote:
> Hi Michael,
>
> Sorry I didn't see this mail sooner -
>
> On 30 July 2015 at 10:36, Michael S. Tsirkin wrote:
>
>> This reverts commit 294ce717e0f212ed0763307f3eab72b4a1bdf4d0.
>>
>&g
On 4 August 2015 at 22:36, Michael S. Tsirkin wrote:
> This makes sense, but the description says master will
> close the socket. This makes no sense to me.
> Maybe we should leave the code as is, but rename the message
> to RESET_DEVICE then?
>
That sounds reasonable to me. In my patch I adopte
ght
> thing to do here.
>
> VHOST_RESET_OWNER should happen on vhost_dev_cleanup - it's
> the counterpart of VHOST_SET_OWNER.
>
> Cc: Luke Gorrie
> Signed-off-by: Michael S. Tsirkin
> ---
>
> I think we need this in 2.4 to avoid introducing regressions
> in t
Hilarity can ensue if vhost is left enabled while a guest reboots.
Luke Gorrie (1):
vhost-user: Send VHOST_RESET_OWNER on vhost stop
hw/net/vhost_net.c | 7 +++
1 file changed, 7 insertions(+)
--
2.1.4
(and will usually close it).
Send this message to tell the vhost-user slave that the vhost session
has ended and that session state (e.g. vrings) is no longer valid.
Signed-off-by: Luke Gorrie
---
hw/net/vhost_net.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/net/vhost_net.c b/hw
Hi Anshul,
On Wednesday, November 19, 2014, Anshul Makkar <
anshul.mak...@profitbricks.com> wrote:
>
>
> I have implemented a usermode app that is using vhost-user backend and
> gets direct access to the guest vrings. I am able to receive packets but
> when I post directly to vring and issue kick,
On 27 February 2014 15:49, Michael S. Tsirkin wrote:
> > Michael: Luke has asked to increase the virtio-net virtqueue size.
> > Thoughts?
> >
> > Stefan
>
> Heh you want to increase the bufferbloat?
>
I'm sensitive to this. (I have actually built a commercial anti-bufferbloat
network device for
On 24 February 2014 16:20, Stefan Hajnoczi wrote:
> On Fri, Feb 14, 2014 at 02:43:14PM +0100, Luke Gorrie wrote:
> > In Snabb Switch we are creating a 1:1 mapping between Virtio-net
> > descriptors and VMDq hardware receive descriptors. The VMDq queues
> support
> > 32768
On 24 February 2014 16:20, Stefan Hajnoczi wrote:
> Do you want the 1:1 mapping to achieve best performance or just to
> simplify the coding?
>
We want to keep the real-time constraints on the data plane comfortable.
The question I ask myself is: How long can I buffer packets during
processing
Howdy!
Observation: virtio-net.c hard-codes the vring size to 256 buffers.
Could this reasonably be made configurable, or would that be likely to
cause a problem?
In Snabb Switch we are creating a 1:1 mapping between Virtio-net
descriptors and VMDq hardware receive descriptors. The VMDq queues s
On 13 December 2013 12:14, Antonios Motakis
wrote:
> At runtime vhost-user netdev will detect if the vhost backend is up or down.
> Upon disconnection it will set link_down accordingly and notify virtio-net.
Based on inspection with 'lsof' I think that the v3 reconnect
mechanism leaks socket file
Cool stuff :-)
some thoughts:
On 13 December 2013 12:14, Antonios Motakis
wrote:
> static int vhost_user_recv(int fd, VhostUserMsg *msg)
> {
> ssize_t r = read(fd, msg, sizeof(VhostUserMsg));
Is it worth considering a "timeout and reconnect" check here? I mean
so that if the vhost server
13:58, Stefan Hajnoczi wrote:
> On Tue, May 28, 2013 at 12:10:50PM +0200, Luke Gorrie wrote:
> > On 27 May 2013 11:34, Stefan Hajnoczi wrote:
> >
> > > vhost_net is about connecting the a virtio-net speaking process to a
> > > tun-like device. The problem y
On 4 June 2013 14:56, Michael S. Tsirkin wrote:
> That would mean making snabb switch part of QEMU.
>
Just curious - not suggesting that this is practical - but what would that
mean?
Is the important thing to keep all device implementations in the same
source tree so that QEMU developers can ta
On 4 June 2013 14:49, Julian Stecklina wrote:
> Yes. Btw, progress is being made. Albeit a bit slower than expected. I
> will have to show something "soon".
>
Awesome!
It's already about 9 months since I did my simple proof-of-concept
integration (https://github.com/SnabbCo/QEMU/compare/master..
Howdy,
My brain is slowly catching up with all of the information shared in this
thread. Here is my first attempt to tease out a way forward for Snabb
Switch.
The idea that excites me is to implement a complete PCI device in Snabb
Switch and expose this to the guest at the basic PCI/MMIO/DMA leve
On 30 May 2013 08:46, Stefan Hajnoczi wrote:
> No, it's still security critical. If there were equivalent solutions
> with better security then I'm sure people would accept them. It's
> just that there isn't an equivalent solution yet :).
>
Security-wise this is where I would like to be in the
On 28 May 2013 13:53, Michael S. Tsirkin wrote:
> Yes, you can maybe trade some of this latency for power/CPU cycles by
> aggressive polling. Doing this in a way that does not waste a lot of
> power would be tricky.
>
For what it's worth, here is my mental model right now:
Administrator budget
On 28 May 2013 15:12, Julian Stecklina wrote:
> AFAICS this can be implemented as a new device in qemu without touching
> qemu internals. Except for a way to get file descriptors for guest
> memory. I'll give it a shot today and tomorrow and we'll see how far I
> get...
>
Most intriguing!
On 28 May 2013 13:53, Michael S. Tsirkin wrote:
> Implementing out of process device logic would absolutely be useful for
> qemu, for security.
>
This sounds wonderful from my perspective. The whole PCI device implemented
in my process according to the Virtio spec? What would it take to make thi
Hi Anthony,
On 27 May 2013 18:18, Anthony Liguori wrote:
> It would be very interesting to combine this with vmsplice/splice.
>
Good point. This kernel-centric approach is a very promising one, though
not the design we are exploring in the Snabb Switch project.
Snabb Switch is instead very har
On 27 May 2013 11:34, Stefan Hajnoczi wrote:
> vhost_net is about connecting the a virtio-net speaking process to a
> tun-like device. The problem you are trying to solve is connecting a
> virtio-net speaking process to Snabb Switch.
>
Yep!
> Either you need to replace vhost or you need a tun
Dear qemu-devel hackers,
I am writing to ask for some technical advice. I am making embarrassingly
slow progress on finding a good way to integrate the Snabb Switch
user-space ethernet switch (http://snabb.co/snabbswitch/) with QEMU for
efficient ethernet I/O.
Stefan put us onto the highly promis
24 matches
Mail list logo
