Michael Wu wrote:
Hi,
This patch:
- fixes misc. whitespace/comments
- replaces u16 with __le16/__be16 where appropriate
Signed-off-by: Michael Wu [EMAIL PROTECTED]
Your patch looks OK, but I am going to reject it for now. There are
other patches touching this header coming up, and I would
Andi Kleen wrote:
The man page was supposed to document the kernel, so it's probably
a bug in the manpage. You should send a patch to the manpages
maintainers, with a warning in NOTES that the Linux behaviour
differs from other OS.
OK. Attached patch fixes this and adds comment to the NOTES.
[NETFILTER BRIDGE]
The included patch clears skb-nf_bridge on a nf_reset().
This makes the bridging-ebtables code more inline with the normal netfilter
code.
I need this to work around some problems related to ipsec over a bridge device.
(in combination with Patricks ipsec-NAT patches)
[NETFILTER BRIDGE]
Do not postpone netfilter in the bridge sabotage function
when the packet will be transformed. I need this in combination
with the ipsec-NAT patches (from Patrick McHardy) to be able to
get ipsec traffic over a bridge device.
Signed-off-by: Ludo Stellingwerff [EMAIL
[XFRM]
Many cheap ipsec appliences don't check the Next Header ESP field.
This is not correct according to the RFC's and Linux rightfully does check the
field.
The problem is that some appliences also don't set this value correctly to 4
(IP on IP),
they leave it on 0.
The following patch
Attached is backport of patch from jamal already in the 2.6 kernel -
http://www.kernel.org/hg/linux-2.6/?cmd=changeset;node=061262a38daa1717e8343846bc9a8fd5712bd07a
It would be very nice to see it in the 2.4 kernel as well, as I keep
receiving reports from users that Quagga IPv6 is broken with
Now I can take you even less seriously. In RFC2581, they are talking
about unloading a burst of data into a connection where there has been
significant idle time since the most recent data send.
To be fair Linux would be using TSO in this case too and therefore
cause bursts. But it also would
On Friday 19 August 2005 12:37 am, Wael Noureddine wrote:
The is no RFC violated by being bursty. Show me the RFC where TCP
burstiness is standardized. This is yet another strawman.
You surely know this is a recurring theme in all congestion control RFCs
(RFC2581 in particular),
as well
I'm personally not a big fan of TSO or TOE. They both add a lot of
complexity
to the network stack, and have other downsides. The *best* way to solve
these problems is to engineer technologies to use larger packet sizes. Even
at 9k (or better yet 16k) the advantages of these offload
included netdev...
On Wed, 17 Aug 2005, Ming Zhang wrote:
Hi folks
We ran into this problem when running jumbo frame with iscsi over e1000.
the MTU1500 is fine while jumbo frame can stably reproduce this error.
when meet this error, as reported in iet list, the box still has 600MB
ram
Andi Kleen wrote:
I'm personally not a big fan of TSO or TOE. They both add a lot of complexity
to the network stack, and have other downsides. The *best* way to solve
these problems is to engineer technologies to use larger packet sizes. Even
at 9k (or better yet 16k) the advantages of
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andi Kleen
Sent: Friday, August 19, 2005 9:33 AM
To: John Heffner
Cc: Wael Noureddine; David S. Miller; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED];
I guess we need to approach the memory manager guys and ask them why the
current kernels are having so much trouble getting contiguous memory.
Because memory fragments.
The only long term reliable way is to not allocate buffers PAGE_SIZE.
The stack supports paged skbs for that.
-Andi
-
To
Right. The other issue with jumbos frames (9000MTU) is that
the allocation needed is just over 2 pages for 4K page size
machines (common case). 3 page contig allocations tend to fail
once a server is heavily loaded and memory gets fragmented.
That's just a driver bug. The driver should be
On Friday 19 August 2005 01:00 pm, Leonid Grossman wrote:
-Original Message-
deployment of larger MTUs, but NIC vendors probably can.
This is already done, both on the hardware and on the OS side.
(Sorry if this is getting a bit offtopic for netdev.)
I know of a number of sites who
On the spec website, the current results have it off.
That was because the old implementation violated the congestion
window. With David's new superTSO the next generation of benchmarks
will likely have it on again.
-Andi
-
To unsubscribe from this list: send the line unsubscribe netdev in
the
On Fri, 19 Aug 2005, Ming Zhang wrote:
This is first reported on IET list and then i redo the test with vanilla
2.6.12.4 kernel and everything went fine.
so i suspect if there are special case caused by vendor kernel.
is this 32KB ATOMIC ram allocation request only available in jumbo frame
OK, I've changed the commentary a bit.
David, can you try to get this into 2.6.13?
Thanks.
[TG3]: Fix SerDes detection
A problem was reported by Grant Grundler on an HP rx8620 using IOX
Core LAN partno(A7109-6) 5701 copper NIC. The tg3 driver mistakenly
detects this NIC as having a SerDes PHY
Ahh, okay. I'm pretty sure that SuSE did some changes (not sure what) to
memory management.
I don't think so.
the formula for the size that the current e1000 looks for is something
like
a = MTU roundup to next power of 2
a += 2 (skb_reserve(NET_IP_ALIGN))
a += 16 (skb_reserve 16 by
On Fri, 19 Aug 2005, Andi Kleen wrote:
Ahh, okay. I'm pretty sure that SuSE did some changes (not sure what) to
memory management.
I don't think so.
I could certainly be mistaken. The difference I saw was that suse kernels
recycle the same skb pointers back to our driver, and the redhat
On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote:
...
Changes since 2.6.13-rc5-mm1:
...
-git-netdev-chelsio.patch
-git-netdev-e100.patch
-git-netdev-sis190.patch
-git-netdev-smc91x-eeprom.patch
-git-netdev-ieee80211-wifi.patch
-git-netdev-upstream.patch
+git-netdev-all.patch
I am sorry that the guy who found this problem is running suse linux,
but with vanilla kernel. so this is a generic problem, not suse
specific.
I am sorry for my insaneness at that time. :P
Ming
On Fri, 2005-08-19 at 20:01 +0200, Andi Kleen wrote:
I could certainly be mistaken. The
I find the no toe, no way attitude strange.
I've seen a number of server applications that:
a] move a lot of data over TCP.. let's say around 1 Gbps over a hundred
concurrent flows.
b] spend a significant amount of cycles in the kernel stack doing this.
c] spend the rest of their cycles doing
From: Hasso Tepper [EMAIL PROTECTED]
Date: Fri, 19 Aug 2005 15:13:41 +0300
It would be very nice to see it in the 2.4 kernel as well, as I keep
receiving reports from users that Quagga IPv6 is broken with 2.4 kernel.
Without this patch it's not possible to support IPv6 routing in Quagga
On Fri, 19 Aug 2005, Andi Kleen wrote:
the formula for the size that the current e1000 looks for is something
like
a = MTU roundup to next power of 2
a += 2 (skb_reserve(NET_IP_ALIGN))
a += 16 (skb_reserve 16 by __dev_alloc_skb)
so, a = 2048 + 2 + 16, or 2066
request (a) from
For jumbo traffic, if cong. window is big, than TSO defer will not
happen that often. Hence, most of the traffic will be non-TSO and that
is why we saw performance degradation on our setup. This was the case
for 10G network where we tend to set tcp window very big, i.e. 1M+
This patch forces to
Is there any reason why PHYLIB is a user-visible option?
As far as I understand it, PHYLIB and the MII PHY device drivers are an
internal library drivers should start to use roughly similar to MII.
But in this case, the options shouldn't be user-visible.
cu
Adrian
--
Is there not
Adrian Bunk wrote:
Is there any reason why PHYLIB is a user-visible option?
As far as I understand it, PHYLIB and the MII PHY device drivers are an
internal library drivers should start to use roughly similar to MII.
But in this case, the options shouldn't be user-visible.
This code is
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.14/net/ipv4/ip_input.c
===
--- net-2.6.14.orig/net/ipv4/ip_input.c
+++ net-2.6.14/net/ipv4/ip_input.c
@@ -400,7 +400,7 @@ int ip_rcv(struct sk_buff *skb, struct n
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.14/net/ipv4/ip_input.c
===
--- net-2.6.14.orig/net/ipv4/ip_input.c
+++ net-2.6.14/net/ipv4/ip_input.c
@@ -279,6 +279,58 @@ int ip_local_deliver(struct sk_buff *skb
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.14/net/ipv4/ip_output.c
===
--- net-2.6.14.orig/net/ipv4/ip_output.c
+++ net-2.6.14/net/ipv4/ip_output.c
@@ -200,7 +200,7 @@ static inline int ip_finish_output2(stru
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.14/net/ipv4/ip_input.c
===
--- net-2.6.14.orig/net/ipv4/ip_input.c
+++ net-2.6.14/net/ipv4/ip_input.c
@@ -361,6 +361,7 @@ drop:
int ip_rcv(struct sk_buff *skb, struct
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.14/include/asm-i386/checksum.h
===
--- net-2.6.14.orig/include/asm-i386/checksum.h
+++ net-2.6.14/include/asm-i386/checksum.h
@@ -83,7 +83,7 @@ static inline unsigned short
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.14/net/ipv4/ip_input.c
===
--- net-2.6.14.orig/net/ipv4/ip_input.c
+++ net-2.6.14/net/ipv4/ip_input.c
@@ -333,16 +333,16 @@ drop:
static inline int ip_rcv_finish(struct
On Sat, Aug 20, 2005 at 03:14:15AM +0200, Thomas Graf wrote:
+ len = ntohs(iph-tot_len);
+ if (skb-len len || len (iph-ihl*4))
+ goto inhdr_error;
If you rewrite it to something like
u32 minlen = skb-len;
if (minlen iph-ihl*4)
minlen =
When the date was Friday 19 August 2005 19:51, Jesse Brandeburg wrote:
included netdev...
On Wed, 17 Aug 2005, Ming Zhang wrote:
Hi folks
We ran into this problem when running jumbo frame with iscsi over e1000.
the MTU1500 is fine while jumbo frame can stably reproduce this error.
When the date was Friday 19 August 2005 20:33, Jesse Brandeburg wrote:
PS we have a driver in test that won't do the large contig allocations any
more.
In fact, I tested a version of these drivers about 3 months ago and not only
they didn't solve the problem, but the throughput decreased!
Is
Thomas Graf wrote:
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.14/net/ipv4/ip_input.c
===
--- net-2.6.14.orig/net/ipv4/ip_input.c
+++ net-2.6.14/net/ipv4/ip_input.c
@@ -279,6 +279,58 @@ int ip_local_deliver(struct
How about uninlining this? Options are rare and options parsing
is rather expensive anyway.
You would need explicit noinline because even without inline gcc
with unit-at-a-time would happily inline it.
-Andi
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
[EMAIL PROTECTED] wrote:
Jeff:
The attached file is the incremental patch to the original uli526x.c I send
you first time,
I modify the source according to your advice, thanks.
Signed-off-by: Peer Chen [EMAIL PROTECTED]
(See attached file: patch_uli526x_inc)
Patch applied, thanks much.
I
40 matches
Mail list logo
