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
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 Hellwig
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 cur
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 d
Rusty Russell wrote:
> On Wed, 2007-04-11 at 17:28 +0300, Avi Kivity wrote:
>
>> Rusty Russell wrote:
>>
>>> On Wed, 2007-04-11 at 07:26 +0300, Avi Kivity wrote:
>>>
>>>
>>>> Nope. Being async is critical for copyless net
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 bl
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 si
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-netdev&m=112262743505711&w=2
I don't really understand what you're
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:
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:
> 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
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 Gu
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 dri
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-spac
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?
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 crash
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 users
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
> i
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: p
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 complet
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 that
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 cache.
22 matches
Mail list logo
