On 01/18/2018 07:51 PM, Avi Kivity wrote:
On 01/18/2018 05:46 PM, Jeff Moyer wrote:
FYI, this kernel has issues. It will boot up, but I don't have
networking, and even rebooting doesn't succeed. I'm looking into it.
FWIW, I'm running an older version of this patchset on my desktop
On 01/18/2018 05:46 PM, Jeff Moyer wrote:
FYI, this kernel has issues. It will boot up, but I don't have
networking, and even rebooting doesn't succeed. I'm looking into it.
FWIW, I'm running an older version of this patchset on my desktop with
no problems so far.
-Jeff
Christoph
Rusty Russell wrote:
On Wednesday 12 December 2007 23:54:00 Dor Laor wrote:
commit 763769621d271d92204ed27552d75448587c1ac0
Author: Dor Laor [EMAIL PROTECTED]
Date: Wed Dec 12 14:52:00 2007 +0200
[virtio-net][PATCH] Don't arm tx hrtimer with a constant 50us each
transmit
The
Rusty Russell wrote:
On Thu, 2007-04-12 at 06:32 +0300, Avi Kivity wrote:
I hadn't considered an always-blocking (or unbuffered) networking API.
It's very counter to current APIs, but does make sense with things like
syslets. Without syslets, I don't think it's very useful as you need
Rusty Russell wrote:
On Wed, 2007-04-11 at 07:26 +0300, Avi Kivity wrote:
Nope. Being async is critical for copyless networking:
- in the transmit path, so need to stop the sender (guest) from touching
the memory until it's on the wire. This means 100% of packets sent will
be blocked
Evgeniy Polyakov wrote:
On Mon, Apr 09, 2007 at 04:38:18PM +0300, Avi Kivity ([EMAIL PROTECTED])
wrote:
But I don't get this we can enhance the kernel but not userspace vibe
8(
I've been waiting for network aio since ~2003. If it arrives in the
next few days, I'm all
Evgeniy Polyakov wrote:
But it looks from this discussion, that it will not prevent from
changing in-kernel driver - place a hook into skb allocation path and
allocate data from opposing memory - get pages from another side and put
them into fragments, then copy headers into skb-data.
Evgeniy Polyakov wrote:
This is what Xen does. It is actually less performant than copying, IIRC.
The problem with flipping pages around is that physical addresses are
cached both in the kvm mmu and in the on-chip tlbs, necessitating
expensive page table walks and tlb invalidation IPIs.
Evgeniy Polyakov wrote:
On Tue, Apr 10, 2007 at 03:17:45PM +0300, Avi Kivity ([EMAIL PROTECTED]) wrote:
Check a link please in case we are talking about different ideas:
http://marc.info/?l=linux-netdevm=112262743505711w=2
I don't really understand what you're testing
Rusty Russell wrote:
On Mon, 2007-04-09 at 16:38 +0300, Avi Kivity wrote:
Moreover, some things just don't lend themselves to a userspace
abstraction. If we want to expose tso (tcp segmentation offload), we
can easily do so with a kernel driver since the kernel interfaces are
all tso
Rusty Russell wrote:
On Sun, 2007-04-08 at 08:36 +0300, Avi Kivity wrote:
Rusty Russell wrote:
Hi Avi,
I don't think you've thought about this very hard. The receive copy is
completely independent with whether the packet is going to the guest via
a kernel driver or via
Rusty Russell wrote:
On Mon, 2007-04-09 at 10:10 +0300, Avi Kivity wrote:
Rusty Russell wrote:
I'm a little puzzled by your response. Hmm...
lguest's userspace network frontend does exactly as many copies as
Ingo's in-host-kernel code. One from the Guest, one
Rusty Russell wrote:
On Thu, 2007-04-05 at 10:17 +0300, Avi Kivity wrote:
Rusty Russell wrote:
You didn't quote Anthony's point about it's more about there not being
good enough userspace interfaces to do network IO.
It's easier to write a kernel-space network driver, but it's
Ingo Molnar wrote:
so right now the only option for a clean codebase is the KVM in-kernel
code.
I strongly disagree with this. Bad code in userspace is not an excuse
for shoving stuff into the kernel, where maintaining it is much more
expensive, and the cause of a mistake can be system
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
so right now the only option for a clean codebase is the KVM
in-kernel code.
I strongly disagree with this.
are you disagreeing with my statement that the KVM kernel-side code is
the only clean codebase here? To me
Rusty Russell wrote:
You didn't quote Anthony's point about it's more about there not being
good enough userspace interfaces to do network IO.
It's easier to write a kernel-space network driver, but it's not
obviously the right thing to do until we can show that an efficient
packet-level
David Miller wrote:
From: Christoph Hellwig [EMAIL PROTECTED]
Date: Wed, 26 Jul 2006 11:04:31 +0100
And to be honest, I don't think adding all this code is acceptable
if it can't replace the existing aio code while keeping the
interface. So while you interface looks pretty sane the
Arjan van de Ven wrote:
From: Arjan van de Ven [EMAIL PROTECTED]
Linux version 2.6.17-git22 ([EMAIL PROTECTED]) (gcc version 4.0.3
(Ubuntu 4.0.3-1ubuntu5)) #20 PREEMPT Tue Jul 4 10:35:04 CEST 2006
[ 2381.598609] =
[ 2381.619314] [ INFO:
Ingo Oeser wrote:
Hi Jörn,
On Saturday, 22. April 2006 13:48, Jörn Engel wrote:
Unless I completely misunderstand something, one of the main points of
the netchannels if to have *zero* fields written to by both producer
and consumer.
Hmm, for me the main point was to keep the
Andi Kleen wrote:
Don't forget that there are benefits of not polluting the cache with the
traffic for the incoming skbs.
Is that a general benefit outside benchmarks? I would expect
most real programs to actually do something with the data
- and that usually involves needing it in
Andi Kleen wrote:
As an example, an NFS server reads some data pages using iSCSI and sends
them using NFS/TCP (or vice versa).
For TX this can be done zero copy using a sendfile like setup.
Yes, or with aio send for anonymous memory.
For RX it may help - but my point was
21 matches
Mail list logo
