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
Andrew Morton wrote:
> On Mon, 4 Feb 2008 13:46:13 -0800 (PST)
> [EMAIL PROTECTED] wrote:
>>
>> Open a tun device as type TUN, set the TUN_NO_PI flag, and try sending an
>> IPv6
>> packet. The packet appears at the interface under tcpdumps, but propagates no
>> further. This is because the defaul
Hi Rusty,
Sorry for delay in reply. I totally missed this one. Need to fix my mail
filters.
See below.
Rusty Russell wrote:
> (No real change, just updated with new bits)
>
> The problem with introducing IFF_RECV_CSUM and IFF_RECV_GSO is that
> they need to set dev->features to enable GSO and/
Folks,
I just got this panic report against 2.6.18 kernel and was wondering if some of
you have
an idea of why this might happen.
The panic looks like this:
skb_over_panic: text:880463db len:2840 put:1454 head:81005df81000
data:81005df81020
tail:81005df81b38 end:81005df
Hi Jon,
Acknowledged. We'll deliver it along with
some other patches ASAP.
Thanx
Did you get a chance to look at my other patch for the header packing ?
Max
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Max Krasnyansky wrote:
Fixes an oops in the non-blocking mode.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
net/tipc/socket.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 2a6a5a6..767f791 100644
--- a/ne
Dave, Alan, Jon,
Max Krasnyansky wrote:
TIPC code is a bit inconsistent in masking out upper bits of various
message fields when packing them into the headers. For the most part
things seem to be ok but we happened to hit a corner case in our labs
when broadcast counter reached certain value
d was messing up status bits in the header. At which point
the link was busted and required a reset to bring it back up.
It's much safer to apply proper mask in the function that does the
actual packing rather than doing it all over the place, and missing a
few ;-).
Signed-off-by: Max Krasnyans
Fixes an oops in the non-blocking mode.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
net/tipc/socket.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 2a6a5a6..767f791 100644
--- a/net/tipc/socket.c
+++ b/ne
Evgeniy Polyakov wrote:
I'm almost convinced that remap can brake even with ring buffer at 1500
sizes. However we're talking about total per packet overhead here. At some
point you have to _unmap_ the thing once user-space app is done with it.
With ring buffer it's "memcpy()/kfree_skb()" where w
Evgeniy Polyakov wrote:
Couple of numbers...
Remapping of the physical page took about 25-50% less time than 1500
bytes copying using memcpy().
And 15 times faster just after reboot, i.e. without anything in the
cache.
CPU is Xeon with HT enabled:
cpu family : 15
model : 2
model n
Evgeniy,
The latest version is available at
http://tservice.net.ru/~s0mbre/archive/af_tlb
It has several enhancements, fixed some stuff,
many cleanups. Fixed/upgraded skb freeing mechanism.
Thanks. I'll take a look at it.
I think this zero-copy mechanism
can be used in tun/tap devices too
Jamal,
Thanx for forwarding. Somehow I didn't see this one. I guess it's time for me
to check my linux-kernel and netdev subscriptions :).
Basic idea behind zero-copy is remapping of the
physical pages where skb->data lives to the
userspace process.
According to my tests, which can be found c
13 matches
Mail list logo
