Recent updates:
* various minor fixes and feature additions
git users: 'ALL' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.13-rc7-netdev1.patch.bz2
drivers/net/wireless/ieee802
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
Same patch as before, only following Dave's advice to not change the
link type of an interface while its up.
-m
--
Mike Kershaw/Dragorn <[EMAIL PROTECTED]>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
Some people are like slinkies. They're not actually good for anythin
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
>
> The tx_lock wo
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: 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, bn
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 24 Aug 2005 00:44:28 +0200
> Well, the hybrid scheme could lead to RX starvation (if some fool
> succeed to transmit at full Gigabit speed), tg3_tx() could loop
> forever, never returning to tg3_poll().
We only should capture the producer/consumer
Eric Dumazet a écrit :
David S. Miller a écrit :
The only thing truly expensive in tg3_tx() are the DMA unmaps on some
platforms, particular if that platform uses an IOMMU. Unfortunately,
you won't see the IOMMU unmapping overhead in the oprofile traces
because the locking done by IOMMU layers
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 24 Aug 2005 00:00:51 +0200
> I believe the tg3_tx() holds the tx_lock for too long, in the case
> 200 or so skb are delivered
>
> Maybe adding a netif_stop_queue(dev) at the beginning of this
> function would help ? Or adding yet another bit in to
Eric Dumazet a écrit :
Given that only one skb (the first in the queue) could have the property
'already given to taps', I believe
we could use one bit at queue level : If set (by a previous requeue),
then the first packet *should not* be resent to taps.
Hum... no... I forgot a qdisc can ha
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 ne
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 us
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, i
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 sto
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: 3
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 %
pfifo_fa
Arnaldo,
Well done although I think you undersell yourself a little as we had
this performance a while ago and then it just dropped temporarily
while you improved the code!
I will test later today on our emulation network with loss and delay
introduced and post the results back.
Regards,
Ian
O
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
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
* 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, &ret))
>
* 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
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 enqueue(
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
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 les
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc6-mm2-mv643xx-enet/drivers/net/mii.c
===
--- linux-2.6.13-rc6-mm2-mv643xx-enet.orig/drivers/net/mii.c
+++ linux-2.6.13-rc6-mm2-mv643xx-enet/drivers/net/mii.c
@@
Dave. Can you apply?
Signed-off-by: Robert Olsson <[EMAIL PROTECTED]>
Thanks.
--ro
Stephen Hemminger writes:
> This is a redo of earlier cleanup stuff:
> * replace DBG() macro with pr_debug()
> * get rid of duplicate extern's that are alread
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
* 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 chain
>
> 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
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
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 tbf_cr
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_REASMUSRMSG
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: "Leonid Grossman" <[EMAIL PROTECTED]>
Date: Tue, 23 Aug 2005 12:08:21 -0400
> There are also stack implementations that support transmit for more than
> one packet at the time, and the improvements are noticeable.
Yes, this is Solaris's "poor man's TSO" :-)
There are actually some non-triv
> -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
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
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 throwin
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 s
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
> > (e
> -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
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
Hi,
I'm learning native IPsec in Linux kernel 2.6. and use IPsec-Tools as
my user-space tools.
In net/key/af_key.c, there are something about PF_KEY as follows:
static struct xfrm_mgr pfkeyv2_mgr =
{
.id = "pfkeyv2",
.notify = pfkey_send_notify,
.
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.
Signed-off-by
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 Deepak,
Yes, please!
On Tue, Aug 23, 2005 at 01:36:03AM -0700, Deepak Saxena wrote:
> 2) On the IXDP2x01 platforms, the chip is connected to a 32-bit addressable
>bus and we have to play tricks with the I/O address and have custom
>inw/outw functions (see include/asm-arm/arch-ixp200
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
#if
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
47 matches
Mail list logo
