On Tue, Oct 02, 2007 at 05:29:11PM +0200, Patrick McHardy wrote:
I think this doesn't completely fix it, when dev_unicast_add is
interrupted by dev_mc_add before the unicast changes are performed,
they will get committed in the dev_mc_add context, so we might still
call change_flags with BH
Hello
This is a repost, there seems to have a misunderstanding before.
I hope this is the right place to ask this. Does any know if there is a
substantial difference in the performance of the traffic controller
between kernel 2.4 and 2.6. We tested it using 1 iperf server and use
250 and 500
Sonny a écrit :
Hello
This is a repost, there seems to have a misunderstanding before.
I hope this is the right place to ask this. Does any know if there is a
substantial difference in the performance of the traffic controller
between kernel 2.4 and 2.6. We tested it using 1 iperf server and
David Miller wrote:
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 2 Oct 2007 18:43:25 -0300
I think that helping ctags to find the definition for the debug variable
to see, for instance, if it is a bitmask or a boolean without having to
chose from tons of 'debug' variables is
Tangential aside:
On Tue, 02 Oct 2007, Rick Jones wrote:
*) depending on the quantity of CPU around, and the type of test one is
running,
results can be better/worse depending on the CPU to which you bind the
application. Latency tends to be best when running on the same core as takes
On tis, 2007-10-02 at 21:59 -0700, Stephen Hemminger wrote:
On Wed, 03 Oct 2007 03:34:34 +0200
Ian Kumlien [EMAIL PROTECTED] wrote:
On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote:
Remove unneeded check that caused problems with jumbo frame sizes.
The check was recently
From: [EMAIL PROTECTED] (Larry McVoy)
Date: Tue, 2 Oct 2007 15:36:44 -0700
On Tue, Oct 02, 2007 at 03:32:16PM -0700, David Miller wrote:
I'm starting to have a theory about what the bad case might
be.
A strong sender going to an even stronger receiver which can
pull out packets into
On 10/3/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Sonny a écrit :
Hello
This is a repost, there seems to have a misunderstanding before.
I hope this is the right place to ask this. Does any know if there is a
substantial difference in the performance of the traffic controller
between
I'm a bit behind after investigating the TCP performance issues that
turned out to be HW specific problems. It's a bit of a
dissapointment, I thought maybe there was a cool bug to fix in TCP :-)
Anyways, that means there are patches backlogged in my inbox and it is
also about time to do the
1) Passing wrong skb to tcp_adjust_fackets_out could corrupt
fastpath_cnt_hint as tcp_skb_pcount(next_skb) is not included
to it if hint points exactly to the next_skb (it's lagging
behind, see sacktag).
2) When fastpath_skb_hint is put backwards to avoid dangling
skb reference, the skb's pcount
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/tcp.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index f8cf090..9ff456e 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -343,7 +343,8 @@ struct
Hi Dave,
Sacktag fastpath_cnt_hint seems to be very tricky to get right...
I suppose this one fixes Cedric's case. I cannot say for sure
until there is something more definite indication of
tcp_retrans_try_collapse origin than what the simple late WARN_ON
gave for us. ...Especially since it's
This should no longer be necessary because fackets_out is
accurate. It indicates bugs elsewhere, thus report it.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/tcp_input.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_input.c
Hello Ilpo !
Ilpo Järvinen wrote:
Hi Dave,
Sacktag fastpath_cnt_hint seems to be very tricky to get right...
I suppose this one fixes Cedric's case. I cannot say for sure
until there is something more definite indication of
tcp_retrans_try_collapse origin than what the simple late
On Wed, 3 Oct 2007, Cedric Le Goater wrote:
Ilpo Järvinen wrote:
Sacktag fastpath_cnt_hint seems to be very tricky to get right...
I suppose this one fixes Cedric's case. I cannot say for sure
until there is something more definite indication of
tcp_retrans_try_collapse origin than
Ilpo Järvinen wrote:
On Wed, 3 Oct 2007, Cedric Le Goater wrote:
Ilpo Järvinen wrote:
Sacktag fastpath_cnt_hint seems to be very tricky to get right...
I suppose this one fixes Cedric's case. I cannot say for sure
until there is something more definite indication of
On Tue, 2007-02-10 at 10:43 -0700, Kok, Auke wrote:
the description of this patch is rather misleading, and the title certainly
too.
That was fast - you said weeks, not days;-
Can you resend this with a bit more elaborate explanation as to why the cb
code is
relevant to use here? Not
On Tue, 2007-02-10 at 16:33 -0700, Michael Chan wrote:
Seems ok to me. I think we should make it more clear that we're
skipping over the VLAN tag:
(struct tg3_tx_cbdata *)((__skb)-cb[sizeof(struct vlan_skb_tx_cookie)])
Will do - thanks Michael.
cheers,
jamal
-
To unsubscribe from this
On Wed, 3 Oct 2007, Cedric Le Goater wrote:
Ilpo Järvinen wrote:
On Wed, 3 Oct 2007, Cedric Le Goater wrote:
I'm dropping the previous patches you sent me and switching to this
patchset.
right ?
Yes you can do that... However, there are two ways forward:
1) Drop and test
On Wed, 2007-03-10 at 01:29 -0400, Bill Fink wrote:
It does sound sensible. My own decidedly non-expert speculation
was that the big 30 % performance hit right at 4 KB may be related
to memory allocation issues or having to split the skb across
multiple 4 KB pages.
plausible. But i also
Hello,
David Stevens wrote:
Dmitry,
Good catch; a couple comments:
Thank you for the response.
struct ipv6_pinfo *np = inet6_sk(sk);
int err;
+ int addr_type = ipv6_addr_type(addr);
+
+ if (addr_type == IPV6_ADDR_MAPPED) {
+ __be32 v4addr = addr-s6_addr32[3];
+
[EMAIL PROTECTED] wrote:
From: Andrew Morton [EMAIL PROTECTED]
net/sctp/sm_statetable.c:551: error: 'sctp_sf_tabort_8_4_8' undeclared here
(not in a function)
Andrew, is the a result of the merge of net-2.6.24 with net-2.6?
That's the only way I see this happening.
Signed-off-by:
Ilpo Järvinen wrote:
On Wed, 3 Oct 2007, Cedric Le Goater wrote:
Ilpo Järvinen wrote:
On Wed, 3 Oct 2007, Cedric Le Goater wrote:
I'm dropping the previous patches you sent me and switching to this
patchset.
right ?
Yes you can do that... However, there are two ways forward:
1) Drop
On Wed, 3 Oct 2007, Cedric Le Goater wrote:
Ilpo Järvinen wrote:
Ah, that's path 1) then... Since you seem to have enough time, I would say
that the path 1 is good as well and bugs unrelated to the fix will show up
there too...
arg. yes. sorry for the confusion.
I should have
On Tue, Oct 02, 2007 at 07:01:56PM -0700, David Miller wrote:
From: John W. Linville [EMAIL PROTECTED]
Date: Tue, 2 Oct 2007 21:25:52 -0400
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-davem
This doesn't pull cleanly.
Probably you used a
When the ICMPv6 Target address is multicast, Linux processes the
redirect instead of dropping it. The problem is in this code in
ndisc_redirect_rcv():
if (ipv6_addr_equal(dest, target)) {
on_link = 1;
} else if (!(ipv6_addr_type(target) IPV6_ADDR_LINKLOCAL)) {
Ilpo Järvinen wrote:
On Wed, 3 Oct 2007, Cedric Le Goater wrote:
Ilpo Järvinen wrote:
Ah, that's path 1) then... Since you seem to have enough time, I would say
that the path 1 is good as well and bugs unrelated to the fix will show up
there too...
arg. yes. sorry for the confusion.
I
Cedric Le Goater wrote:
Ilpo Järvinen wrote:
On Wed, 3 Oct 2007, Cedric Le Goater wrote:
Ilpo Järvinen wrote:
Ah, that's path 1) then... Since you seem to have enough time, I would say
that the path 1 is good as well and bugs unrelated to the fix will show up
there too...
arg. yes. sorry
Cedric Le Goater wrote:
Ilpo Järvinen wrote:
On Wed, 3 Oct 2007, Cedric Le Goater wrote:
Ilpo Järvinen wrote:
Ah, that's path 1) then... Since you seem to have enough time, I would say
that the path 1 is good as well and bugs unrelated to the fix will show up
there too...
arg. yes. sorry
Subject: net: fix race in process_backlog
The recent NAPI rework (4fa57c9ea9f36f9ca852f3a88ca5d2f1aebbc960)
introduced a race between netif_rx() and process_backlog() which
resulted in softirq processing to drop dead.
netif_rx() process_backlog()
On Wed, 03 Oct 2007 17:44:53 +0200
Peter Zijlstra [EMAIL PROTECTED] wrote:
Subject: net: fix race in process_backlog
The recent NAPI rework (4fa57c9ea9f36f9ca852f3a88ca5d2f1aebbc960)
introduced a race between netif_rx() and process_backlog() which
resulted in softirq processing to drop
This patch makes numerous miscellaneous code improvements to the QE library.
1. Remove struct ucc_common and merge ucc_init_guemr() into ucc_set_type()
(every caller of ucc_init_guemr() also calls ucc_set_type()). Modify all
callers of ucc_set_type() accordingly.
2. Remove the unused enum
On Wed, 3 Oct 2007 11:34:59 -0500
Timur Tabi [EMAIL PROTECTED] wrote:
This patch makes numerous miscellaneous code improvements to the QE library.
1. Remove struct ucc_common and merge ucc_init_guemr() into ucc_set_type()
(every caller of ucc_init_guemr() also calls ucc_set_type()).
Reported by a Fedora user this morning.
Ethernet Channel Bonding Driver: v3.1.3 (June 13, 2007)
bonding: MII link monitoring set to 100 ms
ADDRCONF(NETDEV_UP): bond0: link is not ready
bonding: bond0: Adding slave eth0.
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
bonding: bond0:
John W. Linville wrote:
The following changes since commit 3146b39c185f8a436d430132457e84fa1d8f8208:
Linus Torvalds (1):
Linux 2.6.23-rc9
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
fixes-jgarzik
Joe Perches (1):
Stephen Hemminger wrote:
Remove unneeded check that caused problems with jumbo frame sizes.
The check was recently added and is wrong.
When using jumbo frames the sky2 driver does fragmentation, so
rx_data_size is less than mtu.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
applied
-
Olof Johansson wrote:
pasemi_mac: clear out old errors on interface open
Clear out any pending errors when an interface is brought up. Since the bits
are sticky, they might be from interface shutdown time after firmware has
used it, etc.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
In
Olof Johansson wrote:
pasemi_mac: use buffer index pointer in clean_rx()
Use the new features in B0 for buffer ring index on the receive side. This
means we no longer have to search in the ring for where the buffer
came from.
Also cleanup the RX cleaning side a little, while I was at it.
David Miller wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 2 Oct 2007 14:52:36 -0700
Please consider using netif_msg_xxx() and module parameter to set
default message level, like other real network drivers already do.
I keep seeing this recommendation, but the two
Olof Johansson wrote:
pasemi_mac: basic error checking
Add some rudimentary error checking to pasemi_mac.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
applied 1-10
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
applied
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Valentine Barshak (by way of Josh Boyer [EMAIL PROTECTED]) wrote:
Fix an obvious typo in emac_xmit_finish.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
applied
-
To unsubscribe from this
On Wed, Oct 03, 2007 at 01:46:16PM -0400, Jeff Garzik wrote:
Olof Johansson wrote:
pasemi_mac: clear out old errors on interface open
Clear out any pending errors when an interface is brought up. Since the
bits
are sticky, they might be from interface shutdown time after firmware has
used
Ian Kumlien wrote:
On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote:
Remove unneeded check that caused problems with jumbo frame sizes.
The check was recently added and is wrong.
When using jumbo frames the sky2 driver does fragmentation, so
rx_data_size is less than mtu.
Confirmed
pasemi_mac: enable iommu support
Enable IOMMU support for pasemi_mac, but avoid using it on non-partitioned
systems for performance reasons.
The user can override this by selecting the PPC_PASEMI_IOMMU_DMA_FORCE
configuration option.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
On Wed,
Stephen Hemminger wrote:
Separate the changes into individual patches to allow for better comment/review
and bisection in case of regression.
That would be too difficult. Some of the changes are single lines, and this
patch has already been approved -- I just cross-posted to netdev because
Olof Johansson wrote:
On Wed, Oct 03, 2007 at 01:46:16PM -0400, Jeff Garzik wrote:
Olof Johansson wrote:
pasemi_mac: clear out old errors on interface open
Clear out any pending errors when an interface is brought up. Since the
bits
are sticky, they might be from interface shutdown time
Olof Johansson wrote:
pasemi_mac: enable iommu support
Enable IOMMU support for pasemi_mac, but avoid using it on non-partitioned
systems for performance reasons.
The user can override this by selecting the PPC_PASEMI_IOMMU_DMA_FORCE
configuration option.
Signed-off-by: Olof Johansson [EMAIL
Normally I wait a day or two between pushes, to queue up patches and
also to avoid annoying my upstream :) But this includes a couple fixes
I felt should be upstreamed sooner rather than later.
Please pull from 'upstream' branch of
sky2 is really the only important fix, the others are trivial.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/sky2.c |3 ---
Quick'n'dirty fix to 100% oops on rmmod rose. Do you want me to
properly unwind everything before .24?
---
Commit a3d384029aa304f8f3f5355d35f0ae274454f7cd aka
[AX.25]: Fix unchecked rose_add_loopback_neigh uses
transformed rose_loopback_neigh var into statically allocated one.
However, on
Roland Dreier [EMAIL PROTECTED] wrote on 09/17/2007 02:47:42 PM:
IPoIB CM handles this properly by gathering together single pages
in
skbs' fragment lists.
Then can we reuse IPoIB CM code here?
Yes, if possible, refactoring things so that the rx skb allocation
code becomes
On ons, 2007-10-03 at 14:04 -0400, Bill Davidsen wrote:
Ian Kumlien wrote:
On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote:
Remove unneeded check that caused problems with jumbo frame sizes.
The check was recently added and is wrong.
When using jumbo frames the sky2 driver does
Alexey Dobriyan wrote:
Quick'n'dirty fix to 100% oops on rmmod rose. Do you want me to
properly unwind everything before .24?
---
Commit a3d384029aa304f8f3f5355d35f0ae274454f7cd aka
[AX.25]: Fix unchecked rose_add_loopback_neigh uses
transformed rose_loopback_neigh var into statically
On Wed, Oct 03, 2007 at 03:04:20PM -0400, Jeff Garzik wrote:
Alexey Dobriyan wrote:
Quick'n'dirty fix to 100% oops on rmmod rose. Do you want me to
properly unwind everything before .24?
---
Commit a3d384029aa304f8f3f5355d35f0ae274454f7cd aka
[AX.25]: Fix unchecked
On Wed, Oct 03, 2007 at 01:05:14PM -0400, Dave Jones wrote:
Reported by a Fedora user this morning.
Ethernet Channel Bonding Driver: v3.1.3 (June 13, 2007)
bonding: MII link monitoring set to 100 ms
ADDRCONF(NETDEV_UP): bond0: link is not ready
bonding: bond0: Adding slave eth0.
e100:
A few notes to the discussion. I've seen one e1000 bug that ended up being
a crappy AMD pre-opteron SMP chipset with a totally useless PCI bus
implementation, which limited performance quite a bit-totally depending on
what you plugged in and in which slot. 10e milk-and-bread-store
32/33 gige
On Tue, Oct 02, 2007 at 02:21:32PM -0700, Larry McVoy wrote:
More data, sky2 works fine (really really fine, like 79MB/sec) between
Linux dylan.bitmover.com 2.6.18.1 #5 SMP Mon Oct 23 17:36:00 PDT 2006 i686
Linux steele 2.6.20-16-generic #2 SMP Sun Sep 23 18:31:23 UTC 2007 x86_64
So this is
On Wed, Oct 03, 2007 at 02:23:58PM -0700, Larry McVoy wrote:
A few notes to the discussion. I've seen one e1000 bug that ended up being
a crappy AMD pre-opteron SMP chipset with a totally useless PCI bus
implementation, which limited performance quite a bit-totally depending on
what you
On Wed, 03 Oct 2007 14:58:07 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Peter Zijlstra [EMAIL PROTECTED]
Date: Wed, 03 Oct 2007 17:44:53 +0200
Index: linux-2.6/net/core/dev.c
===
---
From: Peter Zijlstra [EMAIL PROTECTED]
Date: Wed, 03 Oct 2007 17:44:53 +0200
Index: linux-2.6/net/core/dev.c
===
--- linux-2.6.orig/net/core/dev.c
+++ linux-2.6/net/core/dev.c
@@ -2095,11 +2095,11 @@ static int
From: John W. Linville [EMAIL PROTECTED]
Date: Wed, 3 Oct 2007 10:10:51 -0400
So I'm not sure what happened for you. But I think it must have been
some other anomaly.
Ok, I'll take some detailed notes next time it happens so we can
figure out why :-)
-
To unsubscribe from this list: send the
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 3 Oct 2007 14:39:16 -0400
Normally I wait a day or two between pushes, to queue up patches and
also to avoid annoying my upstream :) But this includes a couple fixes
I felt should be upstreamed sooner rather than later.
Please pull from
On Oct 3, 2007, at 1:00 PM, Timur Tabi wrote:
Stephen Hemminger wrote:
Separate the changes into individual patches to allow for better
comment/review
and bisection in case of regression.
That would be too difficult. Some of the changes are single lines,
and this patch has already
The 8169/8110SC currently announces itself as:
[...]
eth0: RTL8169sc/8110sc at 0x, ..:..:..:..:..:.., XID 1800 IRQ ..
It uses RTL_GIGA_MAC_VER_05 and this part of the changeset can cut
its performance by a factor of
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 3 Oct 2007 15:05:19 -0700
On Wed, 03 Oct 2007 14:58:07 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Peter Zijlstra [EMAIL PROTECTED]
Date: Wed, 03 Oct 2007 17:44:53 +0200
Index: linux-2.6/net/core/dev.c
From: Vlad Yasevich [EMAIL PROTECTED]
Date: Wed, 03 Oct 2007 09:50:55 -0400
[EMAIL PROTECTED] wrote:
From: Andrew Morton [EMAIL PROTECTED]
net/sctp/sm_statetable.c:551: error: 'sctp_sf_tabort_8_4_8' undeclared here
(not in a function)
Andrew, is the a result of the merge of
Available as usual at:
kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.24.git
I resolved the SCTP and network driver conflicts that come standard
with a rebase to Linus's current tree.
We're up to 700 changesets and an 8.7 MB patch, w00t!
I've been using it for an hour or so on my
68 matches
Mail list logo
