Mark McLoughlin wrote:
On Thu, 2008-08-14 at 11:58 +1000, Rusty Russell wrote:
On Thursday 14 August 2008 00:30:16 Mark McLoughlin wrote:
A very simple approach is attached; I did consider doing a TUNGETFLAGS
that would return tun-flags, but I think it's nicer to have a companion
to TUNGETIFF
Heiko Carstens wrote:
On Mon, Jul 14, 2008 at 11:56:18AM -0700, Jeremy Fitzhardinge wrote:
Rusty Russell wrote:
On Monday 14 July 2008 21:51:25 Christian Borntraeger wrote:
Am Montag, 14. Juli 2008 schrieb Hidetoshi Seto:
+ /* Wait all others come to life */
+ while
Hidetoshi Seto wrote:
Heiko Carstens wrote:
Hmm.. probably a stupid question: but what could happen that a real cpu
(not virtual) becomes unresponsive so that it won't schedule a MAX_RT_PRIO-1
prioritized task for 5 seconds?
The original problem (once I heard and easily reproduced) was
.
This is on top of the latest and greatest :). Assuming virt folks are ok with
the API this should go into 2.6.27.
Signed-off-by: Max Krasnyansky [EMAIL PROTECTED]
---
drivers/net/tun.c | 316 +++-
include/linux/if_tun.h | 24 +++-
2 files changed
Rusty Russell wrote:
On Friday 11 July 2008 12:20:07 Max Krasnyansky wrote:
I haven't looked at the virtio stuff much, I was assuming that the host
side of it is still the TUN driver. Is it not ?
Yes, the host side is still tun/tap. The problem is that qemu doesnt know
which multicast
Christian Borntraeger wrote:
Am Donnerstag, 10. Juli 2008 schrieb Max Krasnyansky:
[...]
The second question is do you guys think that QEMU/KVM/LGUEST/etc would
benefit if receive filtering was done by the host OS. Here is a specific
example of what I'm talking about.
We can do what qemu
-chr_filter, 0, sizeof tun-chr_filter);
should be
memset(tun-net_filter, 0, sizeof tun-net_filter);
Cheers,
Shaun
On Wed, Jul 9, 2008 at 3:58 PM, Max Krasnyansky [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Yesterday while fixing xoff stuckiness issue in the TUN
Yesterday while fixing xoff stuckiness issue in the TUN/TAP driver I got
a chance to look into the multicast filtering code in there. And
immediately realized how terribly broken confusing it is. The patch
was originally done by Shaun (CC'ed) and went in without any proper ACK
from me, Dave
. And it's often way more convenient to muck with the TUN settings
directly on the fd instead of using external tool.
Acked-by: Max Krasnyansky [EMAIL PROTECTED]
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux
outstanding TUN patches into a git tree so
that you can pull them in one shot ?
Otherwise if you're ok with applying them one by one please apply this one.
Acked-by: Max Krasnyansky [EMAIL PROTECTED]
___
Virtualization mailing list
Virtualization
Rusty Russell wrote:
Add a IFF_VNET_HDR flag. This uses the same ABI as virtio_net (ie. prepending
struct virtio_net_hdr to packets) to indicate GSO and checksum information.
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
---
drivers/net/tun.c | 90
Rusty Russell wrote:
On Thursday 26 June 2008 05:07:18 Anthony Liguori wrote:
Rusty Russell wrote:
@@ -1563,6 +1561,16 @@ static void setup_tun_net(char *arg)
/* Tell Guest what MAC address to use. */
add_feature(dev, VIRTIO_NET_F_MAC);
add_feature(dev,
Rusty Russell wrote:
This patch modifies tun to allow a vringfd to specify the receive
buffer. Because we can't copy to userspace in bh context, we queue
like normal then use the pull hook to actually do the copy.
More thought needs to be put into the possible races with ring
registration
Rusty Russell wrote:
On Friday 08 February 2008 16:39:03 Max Krasnyansky wrote:
Rusty Russell wrote:
(Changes since last time: we how have explicit IFF_RECV_CSUM and
IFF_RECV_GSO bits, and some renaming of virtio_net hdr)
We use the virtio_net_hdr: it is an ABI already and designed
Rusty Russell wrote:
(Changes since last time: we how have explicit IFF_RECV_CSUM and
IFF_RECV_GSO bits, and some renaming of virtio_net hdr)
We use the virtio_net_hdr: it is an ABI already and designed to
encapsulate such metadata as GSO and partial checksums.
IFF_VIRTIO_HDR means you
15 matches
Mail list logo
