-Original Message-
From: Arnaldo Carvalho de Melo [mailto:[EMAIL PROTECTED]
Leonid,
If not for performance the idea of having LRO, LSO, TSO, etc
implemented in software can possibly simplify the stack as it
would assume that all drivers implement those features, if
not in
On 8/23/05, Leonid Grossman [EMAIL PROTECTED] wrote:
-Original Message-
From: Arnaldo Carvalho de Melo [mailto:[EMAIL PROTECTED]
Leonid,
If not for performance the idea of having LRO, LSO, TSO, etc
implemented in software can possibly simplify the stack as it
would assume
Hi!
I am trying to build up a gigabit network with the following equipment
(all from Netgear):
Same config here.
So if you are using exactly the same equipment, I think that only two points
can cause the problem:
1. One or more devices I am using are not working correctly. What I am
All,
I've been playing around with the CS89x0 driver for one of my embedded
platforms and have come to the conclusion that it is in dire need of a
rewrite. The current driver looks like hack upon hack on top of a 7 year
old sourcebase and each new embedded board that uses it is adding more
On Tue, Aug 23, 2005 at 12:46:05AM +0200, Patrick McHardy wrote:
[FIB_TRIE]: Don't ignore negative results from fib_semantic_match
When a semantic match occurs either success, not found or an error
(for matching unreachable routes/blackholes) is returned. fib_trie
ignores the errors and
Hi Dave:
While I was going through the crypto users recently, I noticed this
bogus kmap in sunrpc. It's totally unnecessary since the crypto
layer will do its own kmap before touching the data. Besides, the
kmap is throwing the return value away.
Here is a patch to get rid of it.
From: Leonid Grossman [EMAIL PROTECTED]
Date: Tue, 23 Aug 2005 02:25:07 -0400
On a more serious note, I'm all in for stateless offloads but I think
that dropping stack support for adapters that don't implement TSO, etc
(either in hardware or in the driver) is a pretty long shot - someone
will
-Original Message-
From: Arnaldo Carvalho de Melo [mailto:[EMAIL PROTECTED]
No, idea would be to have a library that implements TSO in
software, perhaps with function pointers in struct
net_device, if the drivers don't fill the pointers
register_netdev would fill them with
On Tuesday 23 August 2005 17:21, David S. Miller wrote:
From: Leonid Grossman [EMAIL PROTECTED]
Date: Tue, 23 Aug 2005 02:25:07 -0400
On a more serious note, I'm all in for stateless offloads but I think
that dropping stack support for adapters that don't implement TSO, etc
(either in
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 23 Aug 2005 17:53:58 +0200
However the drawback is that you would likely need to
submit the packets as two pieces (payload and header)
which would need more accesses to TX rings and could
slow down the hardware.
I'm not sure the whole software
From: Herbert Xu [EMAIL PROTECTED]
Date: Tue, 23 Aug 2005 22:27:05 +1000
While I was going through the crypto users recently, I noticed this
bogus kmap in sunrpc. It's totally unnecessary since the crypto
layer will do its own kmap before touching the data. Besides, the
kmap is throwing the
On Tuesday 23 August 2005 18:01, David S. Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 23 Aug 2005 17:53:58 +0200
However the drawback is that you would likely need to
submit the packets as two pieces (payload and header)
which would need more accesses to TX rings and could
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
On the other hand it might make sense to do this even on
hardware that doesn't support TSO - many card designs can
submit a list of packets more efficiently than each packet at
a time. If anything the cost of
Patrick McHardy writes:
That fixed it, it boots fine now and passes Vladimir's testcase.
[FIB_TRIE]: Don't ignore negative results from fib_semantic_match
Hello!
Oh thanks for this one... wonder if this one can have confused us too.
Dave can you please...
Signed-off-by: Robert Olsson
From: Vlad Yasevich [EMAIL PROTECTED]
Date: Mon, 22 Aug 2005 15:27:42 -0400
diff --git a/net/sctp/proc.c b/net/sctp/proc.c
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -57,6 +57,7 @@ static struct snmp_mib sctp_snmp_list[]
SNMP_MIB_ITEM(SctpReasmUsrMsgs, SCTP_MIB_REASMUSRMSGS),
From: Thomas Graf [EMAIL PROTECTED]
Date: Mon, 22 Aug 2005 23:28:15 +0200
qdisc_create_dflt() is missing to destroy the newly allocated
default qdisc if the initialization fails resulting in leaks
of all kinds. The only caller in mainline which may trigger
this bug is sch_tbf.c in
From: Patrick McHardy [EMAIL PROTECTED]
Date: Tue, 23 Aug 2005 00:46:05 +0200
[FIB_TRIE]: Don't ignore negative results from fib_semantic_match
When a semantic match occurs either success, not found or an error
(for matching unreachable routes/blackholes) is returned. fib_trie
ignores the
* David S. Miller [EMAIL PROTECTED] 2005-08-23 09:15
There are actually some non-trivial issues wrt. this. We would
need to loop inside of the packet scheduler, and netfilter, to do
correct traffic classification and firewalling.
But I guess we could deal with that by supporting chaining in
From: Thomas Graf [EMAIL PROTECTED]
Date: Tue, 23 Aug 2005 19:00:54 +0200
Setting txqlen of the device to 2*MAX_CHAINLEN should be sufficient
in most cases. We'd probably have to modify the kick/watchdog a bit
to actually get the packets out faster because the enqueue()s would
happen less
Stephen Hemminger writes:
Convert fib_trie to use Read Copy Update. Since all updates to
FIB happen under RTNL mutex (semaphore),
This version is different from earlier RCU patches because:
* only need hlist_add_before_rcu by recoding insert_leaf_info
* only use RCU for read
There are actually some non-trivial issues wrt. this. We would
need to loop inside of the packet scheduler, and netfilter, to do
correct traffic classification and firewalling.
It could be introduced slowly, with some compat code that just
falls back to packet at a time mode (like it has
David S. Miller wrote:
From: Thomas Graf [EMAIL PROTECTED]
Date: Tue, 23 Aug 2005 19:00:54 +0200
Setting txqlen of the device to 2*MAX_CHAINLEN should be sufficient
in most cases. We'd probably have to modify the kick/watchdog a bit
to actually get the packets out faster because the
* David S. Miller [EMAIL PROTECTED] 2005-08-23 10:35
Currently NETIF_F_SG drivers do not wake up the TX queue
until MAX_SKB_FRAGS descriptors are ready, now they'll
have to defer until (N * MAX_SKB_FRAGS) are available.
And even for a low value of N like 3 this is a whopping _54_ TX
I think I must have messed something up with the 2.6.13 backport of
the fib_trie fix. Putting this in will have to wait until this is
resolved.
With the below patch on 2.6.13 no packets are routable after
bootup and the interfaces are brought up, whereas with the
patch reversed things work fine
Dennis [EMAIL PROTECTED] :
[...]
So if you are using exactly the same equipment, I think that only two points
can cause the problem:
You are optimistic :o)
2. Cables not fitting the requirements. I am using CAT 5e actually, but it may
be that this is a part of the problem. Can you say
Thomas Graf wrote:
* David S. Miller [EMAIL PROTECTED] 2005-08-23 10:48
@@ -1508,7 +1508,7 @@ fn_trie_lookup(struct fib_table *tb, con
continue;
}
if (IS_LEAF(n)) {
- if (check_leaf(t, (struct leaf *)n, key, plen, flp,
res,
Hi all
I have strange numbers on a 4 way SMP Opteron machine, with a single tg3 NIC,
linux-2.6.13-rc6
I have about 12000 requeues per second.
oprofile data show high numbers for these related functions :
qdisc_restart() 2.6452 %
dev_queue_xmit() 0.9599 %
pfifo_fast_dequeue() 0.7094 %
Very small patch to allow setting of the link type of the virtual tapX
interfaces in tun/tap. Needed for writing packets of other arp link
types to tap, ie 80211 wireless frames.
Implemented as a simple IOCTL to set the arptype.
-m
--
Mike Kershaw/Dragorn [EMAIL PROTECTED]
GPG Fingerprint:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 23 Aug 2005 23:25:07 +0200
Looking at the qdisc_restart() function, it seems expensive to dequeue a
packet, attempt to xmit it, requeue it, over and over.
Maybe some kind of throtling is necessary ? Or is it a tg3 bug failing to set
a stop
From: Mike Kershaw [EMAIL PROTECTED]
Subject: [Patch] Set link type on tun/tap virtual interface
Date: Tue, 23 Aug 2005 17:28:00 -0400
Very small patch to allow setting of the link type of the virtual tapX
interfaces in tun/tap. Needed for writing packets of other arp link
types to tap, ie
Modify link up/down handling to use the functions from the MII
library. Note that I track link state using the MII PHY registers
rather than the mv643xx chip's link state registers because I think
it's cleaner to use the MII library code rather than writing local
driver support code. It is also
David S. Miller a écrit :
No, all of your cpus are racing to get the transmit lock
of the tg3 driver. Whoever wins the race gets to queue
the packet, the others have to back off.
I believe the tg3_tx() holds the tx_lock for too long, in the case 200 or so
skb are delivered
Maybe adding a
From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 24 Aug 2005 01:10:44 +0200
Looking at tg3_tx() more closely, I am not convinced it really needs
to lock tp-tx_lock during the loop. tp-tx_cons (swidx) is changed
in this function only, and could be changed to an atomic_t
It's one idea, bnx2.c
Both revisions share the same PCI device ID and vendor ID but revision 2
of the device uses SysKonnect's chipset whereas revision 3 of the device
uses Realtek's 8169 chipset.
Credit goes to Christiaan Lutzer [EMAIL PROTECTED] for reporting
the issue and giving the actual value for the different
From: Robert Olsson [EMAIL PROTECTED]
Date: Tue, 23 Aug 2005 19:16:37 +0200
Dave. Can you apply?
Signed-off-by: Robert Olsson [EMAIL PROTECTED]
Done, thanks.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
35 matches
Mail list logo
