[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
> 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
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
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
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 e
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)
m
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
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 net_
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
@@ -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
(Now I've shown my great skill with e-mail, cc'ing this to not one but _two_
invalid e-mail addresses. Sorry for sending this to you twice Dave, you
probably figured it out already, but my actual e-mail address is below.)
Patch compiles (!) and has been tested using a modified ethtool.
Apolog
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 stil
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 pro
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 def
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 20
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
From: "Michael Chan" <[EMAIL PROTECTED]>
Subject: Re: [BUG] tg3 v3.26 patch and "FIBRE" partno(A7109-6)
Date: Fri, 19 Aug 2005 08:54:19 -0700
> OK, I've changed the commentary a bit.
>
> David, can you try to get this into 2.6.13?
It's on it's way, thanks a lot guys.
-
To unsubscribe from this
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 us
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 differe
On Fri, 2005-08-19 at 19:02 +0200, Andi Kleen wrote:
> > 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 buffer
> Each TOE implementation is locked in time by the speed of the NIC.
> Given time, the network stack will -exceed- the speed of
> today's TOE NICs.
>
> You can see this with 100mbps TOE NICs, which are slower than today's
> software net stack, with today's software net stack being more
> featu
> 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 kernels
> seem to march through a much larger range before the values repeat. This
> is all observation based, so I may be completely wrong on this iss
On Fri, 2005-08-19 at 10:33 -0700, Jesse Brandeburg wrote:
> 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.
> >
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
> 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_reser
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 a
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
case
> 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
th
On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc5-mm1:
>...
> git-net.patch
>...
> Subsystem trees
>...
It seems there are too many different 'ipv4_table' variables:
<-- snip -->
...
CC net/ipv4/ipvs/ip_vs_ctl.o
net/ipv4/ipvs/ip_vs_ctl.c:16
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 sit
We all agree that there is a problem, and each is offering a solution. The
point is that claiming stateless offload is ideal and that TOE is just bad
is not objective. Each has its pros and cons. The performance benefits of
TOE have been demonstrated for many real applications, and we've seen qu
> 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
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 meet this error, as reported in iet list, the box
> 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
-
T
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
case? since the regular MTU case goes fine.
> -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]; netdev@
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 thes
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 free
> 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 offloa
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),
> 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 wou
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-al
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 2.
[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 preve
[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 PROTECTED
[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)
Signed-
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 NOT
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
50 matches
Mail list logo
