* Re: [RFT] fib_trie: cleanup
From: David Miller @ 2007-07-26 8:49 UTC (permalink / raw)
To: shemminger; +Cc: bunk, Robert.Olsson, akpm, paulmck, mingo, josh, netdev
In-Reply-To: <20070726094648.3b7301ae@oldman>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Thu, 26 Jul 2007 09:46:48 +0100
> Try this out:
> * replace macro's with inlines
> * get rid of places doing multiple evaluations of NODE_PARENT
No objections from me.
Robert?
^ permalink raw reply
* [RFT] fib_trie: cleanup
From: Stephen Hemminger @ 2007-07-26 8:46 UTC (permalink / raw)
To: Adrian Bunk, Robert Olsson
Cc: Andrew Morton, Paul E. McKenney, Ingo Molnar, Josh Triplett,
netdev
In-Reply-To: <20070725181557.GF3572@stusta.de>
Try this out:
* replace macro's with inlines
* get rid of places doing multiple evaluations of NODE_PARENT
--- a/net/ipv4/fib_trie.c 2007-07-26 09:22:47.000000000 +0100
+++ b/net/ipv4/fib_trie.c 2007-07-26 09:26:19.000000000 +0100
@@ -93,15 +93,8 @@ typedef unsigned int t_key;
#define T_TNODE 0
#define T_LEAF 1
#define NODE_TYPE_MASK 0x1UL
-#define NODE_PARENT(node) \
- ((struct tnode *)rcu_dereference(((node)->parent & ~NODE_TYPE_MASK)))
-
#define NODE_TYPE(node) ((node)->parent & NODE_TYPE_MASK)
-#define NODE_SET_PARENT(node, ptr) \
- rcu_assign_pointer((node)->parent, \
- ((unsigned long)(ptr)) | NODE_TYPE(node))
-
#define IS_TNODE(n) (!(n->parent & T_LEAF))
#define IS_LEAF(n) (n->parent & T_LEAF)
@@ -174,6 +167,16 @@ static void tnode_free(struct tnode *tn)
static struct kmem_cache *fn_alias_kmem __read_mostly;
static struct trie *trie_local = NULL, *trie_main = NULL;
+static inline struct tnode *node_parent(struct node *node)
+{
+ return rcu_dereference((struct tnode *) (node->parent & ~NODE_TYPE_MASK));
+}
+
+static inline void node_set_parent(struct node *node, struct tnode *ptr)
+{
+ rcu_assign_pointer(node->parent,
+ (unsigned long)ptr | NODE_TYPE(node));
+}
/* rcu_read_lock needs to be hold by caller from readside */
@@ -446,7 +449,7 @@ static void tnode_put_child_reorg(struct
tn->full_children++;
if (n)
- NODE_SET_PARENT(n, tn);
+ node_set_parent(n, tn);
rcu_assign_pointer(tn->child[i], n);
}
@@ -481,7 +484,7 @@ static struct node *resize(struct trie *
continue;
/* compress one level */
- NODE_SET_PARENT(n, NULL);
+ node_set_parent(n, NULL);
tnode_free(tn);
return n;
}
@@ -636,7 +639,7 @@ static struct node *resize(struct trie *
/* compress one level */
- NODE_SET_PARENT(n, NULL);
+ node_set_parent(n, NULL);
tnode_free(tn);
return n;
}
@@ -961,24 +964,21 @@ fib_find_node(struct trie *t, u32 key)
static struct node *trie_rebalance(struct trie *t, struct tnode *tn)
{
int wasfull;
- t_key cindex, key;
- struct tnode *tp = NULL;
-
- key = tn->key;
+ t_key cindex, key = tn->key;
+ struct tnode *tp;
- while (tn != NULL && NODE_PARENT(tn) != NULL) {
-
- tp = NODE_PARENT(tn);
+ while (tn != NULL && (tp = node_parent((struct node *)tn)) != NULL) {
cindex = tkey_extract_bits(key, tp->pos, tp->bits);
wasfull = tnode_full(tp, tnode_get_child(tp, cindex));
tn = (struct tnode *) resize (t, (struct tnode *)tn);
tnode_put_child_reorg((struct tnode *)tp, cindex,(struct node*)tn, wasfull);
- if (!NODE_PARENT(tn))
+ tp = node_parent((struct node *) tn);
+ if (!tp)
break;
-
- tn = NODE_PARENT(tn);
+ tn = tp;
}
+
/* Handle last (top) tnode */
if (IS_TNODE(tn))
tn = (struct tnode*) resize(t, (struct tnode *)tn);
@@ -1031,7 +1031,7 @@ fib_insert_node(struct trie *t, int *err
pos = tn->pos + tn->bits;
n = tnode_get_child(tn, tkey_extract_bits(key, tn->pos, tn->bits));
- BUG_ON(n && NODE_PARENT(n) != tn);
+ BUG_ON(n && node_parent(n) != tn);
} else
break;
}
@@ -1083,7 +1083,7 @@ fib_insert_node(struct trie *t, int *err
if (t->trie && n == NULL) {
/* Case 2: n is NULL, and will just insert a new leaf */
- NODE_SET_PARENT(l, tp);
+ node_set_parent((struct node *)l, tp);
cindex = tkey_extract_bits(key, tp->pos, tp->bits);
put_child(t, (struct tnode *)tp, cindex, (struct node *)l);
@@ -1114,7 +1114,7 @@ fib_insert_node(struct trie *t, int *err
goto err;
}
- NODE_SET_PARENT(tn, tp);
+ node_set_parent((struct node *)tn, tp);
missbit = tkey_extract_bits(key, newpos, 1);
put_child(t, tn, missbit, (struct node *)l);
@@ -1495,12 +1495,13 @@ backtrace:
if (chopped_off <= pn->bits) {
cindex &= ~(1 << (chopped_off-1));
} else {
- if (NODE_PARENT(pn) == NULL)
+ struct tnode *parent = node_parent((struct node *) pn);
+ if (!parent)
goto failed;
/* Get Child's index */
- cindex = tkey_extract_bits(pn->key, NODE_PARENT(pn)->pos, NODE_PARENT(pn)->bits);
- pn = NODE_PARENT(pn);
+ cindex = tkey_extract_bits(pn->key, parent->pos, parent->bits);
+ pn = parent;
chopped_off = 0;
#ifdef CONFIG_IP_FIB_TRIE_STATS
@@ -1536,7 +1537,7 @@ static int trie_leaf_remove(struct trie
check_tnode(tn);
n = tnode_get_child(tn ,tkey_extract_bits(key, tn->pos, tn->bits));
- BUG_ON(n && NODE_PARENT(n) != tn);
+ BUG_ON(n && node_parent(n) != tn);
}
l = (struct leaf *) n;
@@ -1551,7 +1552,7 @@ static int trie_leaf_remove(struct trie
t->revision++;
t->size--;
- tp = NODE_PARENT(n);
+ tp = node_parent(n);
tnode_free((struct tnode *) n);
if (tp) {
@@ -1703,7 +1704,7 @@ static struct leaf *nextleaf(struct trie
p = (struct tnode*) trie; /* Start */
} else
- p = (struct tnode *) NODE_PARENT(c);
+ p = node_parent(c);
while (p) {
int pos, last;
@@ -1740,7 +1741,7 @@ static struct leaf *nextleaf(struct trie
up:
/* No more children go up one step */
c = (struct node *) p;
- p = (struct tnode *) NODE_PARENT(p);
+ p = node_parent(c);
}
return NULL; /* Ready. Root of trie */
}
@@ -2043,7 +2044,7 @@ rescan:
}
/* Current node exhausted, pop back up */
- p = NODE_PARENT(tn);
+ p = node_parent((struct node *)tn);
if (p) {
cindex = tkey_extract_bits(tn->key, p->pos, p->bits)+1;
tn = p;
@@ -2317,7 +2318,7 @@ static int fib_trie_seq_show(struct seq_
if (v == SEQ_START_TOKEN)
return 0;
- if (!NODE_PARENT(n)) {
+ if (!node_parent(n)) {
if (iter->trie == trie_local)
seq_puts(seq, "<local>:\n");
else
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Ingo Molnar @ 2007-07-26 8:31 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Jarek Poplawski, Marcin ??lusarz, Linus Torvalds,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton, Alan Cox
In-Reply-To: <1185437431.3227.21.camel@chaos>
* Thomas Gleixner <tglx@linutronix.de> wrote:
> The other question is:
>
> Is the driver confused by the resent irq or is the chip-set unhappy
> about the resend ?
>
> We could figure the latter out by activating the software based resend
> method.
yeah. The patch below enables sw-resend on x86, to test the theory
whether the APIC-driven hardware-vector-resend code has some problem.
Marcin, could you please give this one a try too? Good behavior would be
a fully working kernel (no hung device) with no extra kernel messages.
Bad behavior would be any extra kernel message or any non-working
device.
Ingo
----------------------------->
Subject: x86: activate HARDIRQS_SW_RESEND
From: Ingo Molnar <mingo@elte.hu>
activate the software-triggered IRQ-resend logic.
it appears some chipsets/cpus do not handle local-APIC driven IRQ
resends all that well, so always use the soft mechanism to trigger
the execution of pending interrupts.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/i386/Kconfig | 4 ++++
kernel/irq/manage.c | 8 ++++++++
2 files changed, 12 insertions(+)
Index: linux/arch/i386/Kconfig
===================================================================
--- linux.orig/arch/i386/Kconfig
+++ linux/arch/i386/Kconfig
@@ -1270,6 +1270,10 @@ config GENERIC_PENDING_IRQ
depends on GENERIC_HARDIRQS && SMP
default y
+config HARDIRQS_SW_RESEND
+ bool
+ default y
+
config X86_SMP
bool
depends on SMP && !X86_VOYAGER
Index: linux/kernel/irq/manage.c
===================================================================
--- linux.orig/kernel/irq/manage.c
+++ linux/kernel/irq/manage.c
@@ -181,6 +181,14 @@ void enable_irq(unsigned int irq)
desc->depth--;
}
spin_unlock_irqrestore(&desc->lock, flags);
+#ifdef CONFIG_HARDIRQS_SW_RESEND
+ /*
+ * Do a bh disable/enable pair to trigger any pending
+ * irq resend logic:
+ */
+ local_bh_disable();
+ local_bh_enable();
+#endif
}
EXPORT_SYMBOL(enable_irq);
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Ingo Molnar @ 2007-07-26 8:16 UTC (permalink / raw)
To: Marcin Ślusarz
Cc: Thomas Gleixner, Linus Torvalds, Jarek Poplawski,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton
In-Reply-To: <4bacf17f0707260016x14fc1c92s628ae64353663833@mail.gmail.com>
* Marcin Ślusarz <marcin.slusarz@gmail.com> wrote:
> 2007/7/25, Thomas Gleixner <tglx@linutronix.de>:
> >(...)
>
> I've tested Jarek's patch, 2 Ingo's patches (2nd and 3rd) and Thomas'
> patch (one patch at time of course) - all of them fixed the problem,
> but the last one flooded my logs with "Skip resend for irq 17". All
> tests were done on 2.6.21.3.
that's great! I think we have two good theories about what might be
going on:
- the driver might be buggy in that it gets confused by the 'resent'
irq.
- or the chipset/cpu has a bug where it might get confused about the
resent APIC vector getting mixed up with the same vector coming
externally too. (Now, it makes little sense to 'resend' a
level-triggered interrupt on x86 platforms that have flat PIC
hierarchies (other architectures might need more than that to
retrigger an interrupt) - but there's nothing wrong about it in
theory and it needs fixing for edge irqs anyway.)
in any case, the problem was triggered by our change generating much
more resent irqs than before. Nevertheless we'd like to fix that resend
bug (and if the driver is buggy, the driver bug too). It's really good
progress so far - we are working on doing the real fix now.
Ingo
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Thomas Gleixner @ 2007-07-26 8:10 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Marcin Ślusarz, Ingo Molnar, Linus Torvalds,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton, Alan Cox
In-Reply-To: <20070726081326.GA3197@ff.dom.local>
On Thu, 2007-07-26 at 10:13 +0200, Jarek Poplawski wrote:
> > I wanted to test them all on 2.6.22.1, but I didn't have enough time.
> > I've verified only that 2.6.22.1 has the same problem. I can test it
> > later, but I can report results back at beginning of next week.
>
>
> So, everything is clear - any changes are good!
> Except the signed-off ones...
>
> Thanks Marcin,
> Jarek P.
>
> PS: Now, it seems to me Thomas could be the nearest. BTW, could somebody
> give me some tip, how these re-triggered interrupts are skipped on dev's
> reset before enable_irq?
I think the correct solution is really not to resend level type
interrupts. If the interrupt line is still active, then the interrupt
comes up by itself. I'm cooking a patch for that.
The other question is:
Is the driver confused by the resent irq or is the chip-set unhappy
about the resend ?
We could figure the latter out by activating the software based resend
method.
tglx
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Jarek Poplawski @ 2007-07-26 8:19 UTC (permalink / raw)
To: Marcin Ślusarz
Cc: Thomas Gleixner, Ingo Molnar, Linus Torvalds,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton, Alan Cox
In-Reply-To: <20070726081326.GA3197@ff.dom.local>
On Thu, Jul 26, 2007 at 10:13:26AM +0200, Jarek Poplawski wrote:
...
> So, everything is clear - any changes are good!
> Except the signed-off ones...
Oops! Marcin's patch was both signed-off and good.
So, there is probably something more...
Sorry Marcin,
Jarek P.
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Jarek Poplawski @ 2007-07-26 8:13 UTC (permalink / raw)
To: Marcin Ślusarz
Cc: Thomas Gleixner, Ingo Molnar, Linus Torvalds,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton, Alan Cox
In-Reply-To: <4bacf17f0707260016x14fc1c92s628ae64353663833@mail.gmail.com>
On Thu, Jul 26, 2007 at 09:16:10AM +0200, Marcin Ślusarz wrote:
> 2007/7/25, Thomas Gleixner <tglx@linutronix.de>:
> >(...)
>
> I've tested Jarek's patch, 2 Ingo's patches (2nd and 3rd) and Thomas'
> patch (one patch at time of course) - all of them fixed the problem,
> but the last one flooded my logs with "Skip resend for irq 17". All
> tests were done on 2.6.21.3.
>
> I wanted to test them all on 2.6.22.1, but I didn't have enough time.
> I've verified only that 2.6.22.1 has the same problem. I can test it
> later, but I can report results back at beginning of next week.
So, everything is clear - any changes are good!
Except the signed-off ones...
Thanks Marcin,
Jarek P.
PS: Now, it seems to me Thomas could be the nearest. BTW, could somebody
give me some tip, how these re-triggered interrupts are skipped on dev's
reset before enable_irq?
^ permalink raw reply
* Multicast issues with RTL8110SC in r8169.c
From: Glen Gray @ 2007-07-26 7:33 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20070718221107.GE9755@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 6960 bytes --]
Hey Francois,
I've CC'd the netdev list as requested
Francois Romieu wrote:
>> I'm in a particularly sticky situation in relation to the latest
>> kernels and multicast. And I need some help to get out of it. I'm
>> hoping with your combined experiences we might be able to solve my
>> problems.
>
> Multicast ? It could be worth to try 2.6.22 +
> http://www.fr.zoreil.com/people/francois/misc/20070628-2.6.22-rc6-r8169-test.patch
>
> (same thing as a serie of patches at:
> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628)
>
> The patches are available in the current git kernel tree (and will thus
> appear in 2.6.23-rc1).
>
I've applied that patch to the 2.6.22.1 kernel. I found a fedora source
rpm in the testing dir and modified it to apply your patch.
Unfortunately, this hasn't solved my problems. The tests mentioned below
where also carried out under this kernel with the same effect.
>> that for some reason dhcp wasn't working. After investigations back
>> in our lab we realised that the hardware suppliers had changed the
>> eth chip from the RTL8169S/8110S used in the initial run of units
>> that we developed against to the RTL8169SC/8110SC without telling us.
>
> Can you send a detailled output of mii-tool for both ? Just curious.
>
Sure, but not sure what kind of info you'd like to see though, I'm new
to this side of things. Could you give me some examples of what would be
helpful ?
Here's some data from ethtool
[root@webnote root]# uname -r
2.6.22.1-20.fc7
[root@webnote root]# dmesg | grep eth
eth0: RTL8169sc/8110sc at 0xdc876000, 00:05:6b:40:2c:be, XID 18000000 IRQ 18
r8169: eth0: link up
r8169: eth0: link up
[root@webnote root]# ethtool -i eth0
driver: r8169
version: 2.2LK-NAPI
firmware-version:
bus-info: 0000:00:0b.0
[root@webnote root]# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes
[root@webnote root]# ethtool -S eth0
NIC statistics:
tx_packets: 2666
rx_packets: 21498
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 20392
broadcast: 579
multicast: 536
tx_aborted: 0
tx_underrun: 0
>> I've frantically managed to upgrade the base distro to Fedora 7 with
>> the stock 2.6.21 kernel in the hopes it would resolve our problems.
>> DHCP now works correctly but I'm still having issues. Specifically
>> with multicast.
>
> FC7 with latest FC6 kernel may behave better. There are some issues
> with the last FC7 kernel and the r8169 driver.
>
> However, you should really try the suggestion above first.
>
I've managed to localise the problem a bit better. It looks like its
ethernet multicast that's the problem. We've setup some fixed playlist
items that use IP multicast addresses (what the SAP announcements are
providing) and they play fine. However, the ethernet multicast packets
are either being ignored or something else is wrong as the SAP messages
aren't getting back to the unit.
My colleague in our other office with an exterity iptv gateway captured
some data that I'm including here. I've replicated these tests also
using vlc as a simulated iptv gateway.
Attached are two files. One is a tcpdump from a machine on the same hub
showing the IGMPv2 messages getting sent to the multicast address and
then the subsequent data packets being routed from the iptv gateway
(192.168.3.4) to the unit. There's also a tcpdump from the unit where
you can see the IGMPv2 requests going out, but none of the data coming
back. The first file shows that the multicast session was setup
correctly, but for some reason the unit can't see it.
As mentioned in my original message, we have to force the igmp version
to 2 via the /proc/sys/net/ipv4/conf/eth0/force_igmp_version as it
defaults to V3 (as seen from /proc/net/igmp). The RTL8110S defaulted to V2.
Here is a dump of what the missing data packets look like
Frame 64 (324 bytes on wire, 324 bytes captured)
Arrival Time: Jul 19, 2007 18:16:18.820712000
[Time delta from previous captured frame: 1.020403000 seconds]
[Time delta from previous displayed frame: 1.020403000 seconds]
[Time since reference or first frame: 1184865378.820712000 seconds]
Frame Number: 64
Frame Length: 324 bytes
Capture Length: 324 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:sap:sdp]
Ethernet II, Src: AsustekC_51:f9:19 (00:0e:a6:51:f9:19), Dst:
01:00:5e:7f:ff:ff (01:00:5e:7f:ff:ff)
Destination: 01:00:5e:7f:ff:ff (01:00:5e:7f:ff:ff)
Address: 01:00:5e:7f:ff:ff (01:00:5e:7f:ff:ff)
.... ...1 .... .... .... .... = IG bit: Group address
(multicast/broadcast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: AsustekC_51:f9:19 (00:0e:a6:51:f9:19)
Address: AsustekC_51:f9:19 (00:0e:a6:51:f9:19)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Trailer: 8C0DFBE0
Internet Protocol, Src: 192.168.3.4 (192.168.3.4), Dst: 239.255.255.255
(239.255.255.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 306
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 255
Protocol: UDP (0x11)
Header checksum: 0xc70e [correct]
[Good: True]
[Bad : False]
Source: 192.168.3.4 (192.168.3.4)
Destination: 239.255.255.255 (239.255.255.255)
Kind Regards
--
Glen Gray <glen@lincor.com> Digital Depot, Thomas Street
Senior Software Engineer Dublin 8, Ireland
Lincor Solutions Ltd. Ph: +353 (0) 1 4893682
[-- Attachment #2: newonwire.txt --]
[-- Type: text/plain, Size: 4998 bytes --]
[daveharley@dave-ws ~]$ sudo tcpdump -s 0 ether multicast or ip multicast
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:36:53.793604 IP dave-ws.cork.lincor.com > 224.0.0.251: igmp v2 report 224.0.0.251
16:37:06.139586 arp who-has colorprinter.cork.lincor.com tell netscreen.cork.lincor.com
16:37:07.144003 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:07.293409 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:07.293421 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:07.293658 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:08.273844 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:14.501961 arp who-has homer.cork.lincor.com tell 192.168.3.244
16:37:14.721084 IP colorprinter.cork.lincor.com.netbios-dgm > 192.168.3.255.netbios-dgm: NBT UDP PACKET(138)
16:37:22.821357 IP exterity.cork.lincor.com.hbci > 255.255.255.255.snmptrap: V2Trap(98) system.sysUpTime.0=1 S:1.1.4.1.0=E:38072.1.1000.1 E:38072.1.5=00_0e_a6_51_f9_19_00_00 E:38072.1.10=3
16:37:23.282835 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:23.432243 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:23.432253 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:23.432494 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:24.412678 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:39.421676 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:39.571090 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:39.571108 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:39.571112 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:40.551519 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:49.255189 IP6 fe80::205:6bff:fe40:2cca > ff02::16: HBH ICMP6, multicast listener report v2, 11 group record(s), length 228
16:37:50.085210 IP 192.168.3.243 > SAP.MCAST.NET: igmp v2 report SAP.MCAST.NET
16:37:50.086200 IP 192.168.3.243 > 239.195.255.255: igmp v2 report 239.195.255.255
16:37:50.090198 IP 192.168.3.243 > 239.255.255.255: igmp v2 report 239.255.255.255
16:37:50.092197 IP 192.168.3.243 > 224.0.0.255: igmp v2 report 224.0.0.255
16:37:50.096444 IP6 fe80::205:6bff:fe40:2cca > ff02::16: HBH ICMP6, multicast listener report v2, 11 group record(s), length 228
16:37:53.417015 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 278
16:37:53.417260 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 289
16:37:53.417758 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 277
16:37:53.418008 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 286
16:37:53.418258 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 288
16:37:53.418508 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 289
16:37:53.418758 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 280
16:37:53.419009 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 287
16:37:53.419260 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 275
16:37:53.419510 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 282
16:37:53.420008 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 285
16:37:53.420256 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 286
16:37:53.420507 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 291
16:37:53.427254 IP exterity.cork.lincor.com.hbci > 255.255.255.255.snmptrap: V2Trap(98) system.sysUpTime.0=1 S:1.1.4.1.0=E:38072.1.1000.1 E:38072.1.5=00_0e_a6_51_f9_19_00_00 E:38072.1.10=3
16:37:54.445666 IP6 fe80::205:6bff:fe40:2cca > ff02::16: HBH ICMP6, multicast listener report v2, 11 group record(s), length 228
16:37:54.583587 IP 192.168.3.243 > 239.255.255.255: igmp v2 report 239.255.255.255
16:37:55.550522 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:55.699937 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:55.699958 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:55.700180 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:56.680361 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:56.855763 IP 192.168.3.243 > SAP.MCAST.NET: igmp v2 report SAP.MCAST.NET
16:37:58.218718 IP 192.168.3.243 > 224.0.0.255: igmp v2 report 224.0.0.255
16:37:59.014754 IP 192.168.3.243 > SAP.MCAST.NET: igmp v2 report SAP.MCAST.NET
16:37:59.286846 IP 192.168.3.243 > 239.195.255.255: igmp v2 report 239.195.255.255
16:38:03.050145 IP 192.168.3.243 > 239.255.255.255: igmp v2 report 239.255.255.255
16:38:07.515541 IP 192.168.3.243 > 239.195.255.255: igmp v2 report 239.195.255.255
16:38:08.102457 IP 192.168.3.243 > 224.0.0.255: igmp v2 report 224.0.0.255
54 packets captured
108 packets received by filter
0 packets dropped by kernel
[-- Attachment #3: newonstb.txt --]
[-- Type: text/plain, Size: 4533 bytes --]
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:36:32.671661 arp who-has colorprinter.cork.lincor.com tell 192.168.3.227
16:36:34.830268 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:36:34.979677 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:36:34.979735 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:36:34.979803 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:36:35.960127 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:36:46.238616 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:04:96:05:48:c1 (oui Unknown), length 300
16:36:50.957792 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:36:51.107200 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:36:51.107258 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:36:51.107326 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:36:52.087659 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:36:52.157997 IP exterity.cork.lincor.com.hbci > 255.255.255.255.snmptrap: V2Trap(98) system.sysUpTime.0=1 S:1.1.4.1.0=E:38072.1.1000.1 E:38072.1.5=00_0e_a6_51_f9_19_00_00 E:38072.1.10=3
16:37:06.081091 arp who-has colorprinter.cork.lincor.com tell netscreen.cork.lincor.com
16:37:07.085342 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:07.234749 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:07.234809 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:07.234875 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:08.215186 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:14.442591 arp who-has homer.cork.lincor.com tell 192.168.3.244
16:37:14.661762 IP colorprinter.cork.lincor.com.netbios-dgm > 192.168.3.255.netbios-dgm: NBT UDP PACKET(138)
16:37:22.761320 IP exterity.cork.lincor.com.hbci > 255.255.255.255.snmptrap: V2Trap(98) system.sysUpTime.0=1 S:1.1.4.1.0=E:38072.1.1000.1 E:38072.1.5=00_0e_a6_51_f9_19_00_00 E:38072.1.10=3
16:37:23.222849 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:23.372249 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:23.372317 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:23.372382 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:24.352685 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:39.360368 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:39.509781 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:39.509839 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:39.509906 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:40.490229 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:49.192973 IP6 fe80::205:6bff:fe40:2cca > ff02::16: HBH ICMP6, multicast listener report v2, 11 group record(s), length 228
16:37:50.022991 IP 192.168.3.243 > SAP.MCAST.NET: igmp v2 report SAP.MCAST.NET
16:37:50.023981 IP 192.168.3.243 > 239.195.255.255: igmp v2 report 239.195.255.255
16:37:50.027995 IP 192.168.3.243 > 239.255.255.255: igmp v2 report 239.255.255.255
16:37:50.029991 IP 192.168.3.243 > 224.0.0.255: igmp v2 report 224.0.0.255
16:37:50.034003 IP6 fe80::205:6bff:fe40:2cca > ff02::16: HBH ICMP6, multicast listener report v2, 11 group record(s), length 228
16:37:53.364877 IP exterity.cork.lincor.com.hbci > 255.255.255.255.snmptrap: V2Trap(98) system.sysUpTime.0=1 S:1.1.4.1.0=E:38072.1.1000.1 E:38072.1.5=00_0e_a6_51_f9_19_00_00 E:38072.1.10=3
16:37:54.382979 IP6 fe80::205:6bff:fe40:2cca > ff02::16: HBH ICMP6, multicast listener report v2, 11 group record(s), length 228
16:37:54.521003 IP 192.168.3.243 > 239.255.255.255: igmp v2 report 239.255.255.255
16:37:55.488015 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:55.637426 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:55.637483 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:55.637764 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:56.617871 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:56.792998 IP 192.168.3.243 > SAP.MCAST.NET: igmp v2 report SAP.MCAST.NET
16:37:58.155977 IP 192.168.3.243 > 224.0.0.255: igmp v2 report 224.0.0.255
16:37:58.951975 IP 192.168.3.243 > SAP.MCAST.NET: igmp v2 report SAP.MCAST.NET
16:37:59.223986 IP 192.168.3.243 > 239.195.255.255: igmp v2 report 239.195.255.255
16:38:02.986975 IP 192.168.3.243 > 239.255.255.255: igmp v2 report 239.255.255.255
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Marcin Ślusarz @ 2007-07-26 7:16 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Linus Torvalds, Jarek Poplawski,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton
In-Reply-To: <1185322771.4175.102.camel@chaos>
2007/7/25, Thomas Gleixner <tglx@linutronix.de>:
> (...)
I've tested Jarek's patch, 2 Ingo's patches (2nd and 3rd) and Thomas'
patch (one patch at time of course) - all of them fixed the problem,
but the last one flooded my logs with "Skip resend for irq 17". All
tests were done on 2.6.21.3.
I wanted to test them all on 2.6.22.1, but I didn't have enough time.
I've verified only that 2.6.22.1 has the same problem. I can test it
later, but I can report results back at beginning of next week.
Regards,
Marcin Slusarz
^ permalink raw reply
* Re: [PATCH RFC]: napi_struct V4
From: David Miller @ 2007-07-26 7:15 UTC (permalink / raw)
To: mchan; +Cc: netdev, shemminger, jgarzik, hadi, rusty
In-Reply-To: <1551EAE59135BE47B544934E30FC4FC002AAB9F8@nt-irva-0751.brcm.ad.broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 26 Jul 2007 00:05:47 -0700
> David Miller wrote:
>
> > So that ->poll_controller() can process TX acks by just having
> > the TX lock and interrupts disabled.
> >
> > Can you think of another way to process TX acks from absolutely
> > any execution context whatsoever? That's what we need and
> > preferably in some generic way, and the above is what I came
> > up with.
>
> What are we trying to protect against by taking the TX lock before
> calling ->poll_controller()?
The netpoll code has to take that anyways in order to call
into ->hard_start_xmit() to send out the packet it has
pending, I'm leveraging that as a synchronization mechanism
in the drivers because the locking options are limited
given that netpoll can try to do this in any context whatsoever.
> There is a measurable difference in oprofile. When passing small
> packets, there's a non-trivial difference in throughput.
Then please help come up with an alternate scheme, because these
NAPI changes fix real limitations and bugs in the current code
and unless we fix netpoll too we can't move forward.
Thanks.
^ permalink raw reply
* Re: net/bluetooth/rfcomm/tty.c: use-after-free
From: David Miller @ 2007-07-26 7:12 UTC (permalink / raw)
To: marcel; +Cc: ville.tervo, maxk, netdev, linux-kernel, bunk, bluez-devel
In-Reply-To: <1185176832.7111.32.camel@violet>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Mon, 23 Jul 2007 09:47:12 +0200
> Hi Adrian,
>
> > Commit 8de0a15483b357d0f0b821330ec84d1660cadc4e added the following
> > use-after-free in net/bluetooth/rfcomm/tty.c:
...
> > Spotted by the Coverity checker.
>
> really good catch. I fully overlooked that one. The attached patch
> should fix it.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Applied, thanks everyone.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply
* Re: [PATCH [Bug 8756]] IPv6: Don't update ADVMSS on routes where the MTU is not also updated
From: David Miller @ 2007-07-26 7:10 UTC (permalink / raw)
To: simon; +Cc: netdev, bugme-daemon
In-Reply-To: <46A500B9.3030702@simon.arlott.org.uk>
From: Simon Arlott <simon@fire.lp0.eu>
Date: Mon, 23 Jul 2007 20:25:45 +0100
> The ADVMSS value was incorrectly updated for ALL routes when the MTU
> is updated because it's outside the effect of the if statement's
> condition.
>
> Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Thanks for fixing this bug Simon, patch applied.
^ permalink raw reply
* Re: [PATCH net-2.6.22-rc7] xfrm state selection update to use inner addresses
From: David Miller @ 2007-07-26 7:08 UTC (permalink / raw)
To: kaber; +Cc: joakim.koskela, netdev
In-Reply-To: <46A60D50.804@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 24 Jul 2007 16:31:44 +0200
> Joakim Koskela wrote:
> > This patch modifies the xfrm state selection logic to use the inner
> > addresses where the outer have been (incorrectly) used. This is
> > required for beet mode in general and interfamily setups in both
> > tunnel and beet mode.
>
>
> Looks good.
>
> Acked-by: Patrick McHardy <kaber@trash.net>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] NET_DMA: remove unused dma_memcpy_to_kernel_iovec
From: David Miller @ 2007-07-26 7:06 UTC (permalink / raw)
To: shannon.nelson; +Cc: netdev, viro, christopher.leech, andy.grover
In-Reply-To: <20070725003606.11018.15141.stgit@localhost.localdomain>
From: Shannon Nelson <shannon.nelson@intel.com>
Date: Tue, 24 Jul 2007 17:36:06 -0700
> (repost - original eaten by vger?)
>
> Al Viro pointed out that dma_memcpy_to_kernel_iovec() really was
> unreachable and thus unused. The code originally was there to support
> in-kernel dma needs, but since it remains unused, we'll pull it out.
>
> Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Applied, thanks Shannon.
^ permalink raw reply
* Re: [PATCH RFC]: napi_struct V4
From: Michael Chan @ 2007-07-26 7:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shemminger, jgarzik, hadi, rusty
In-Reply-To: <20070725.233808.41635535.davem@davemloft.net>
David Miller wrote:
> So that ->poll_controller() can process TX acks by just having
> the TX lock and interrupts disabled.
>
> Can you think of another way to process TX acks from absolutely
> any execution context whatsoever? That's what we need and
> preferably in some generic way, and the above is what I came
> up with.
What are we trying to protect against by taking the TX lock before
calling ->poll_controller()?
>
> To be honest I don't think the TX lock contention will matter, and
> even if there were a small cost, the simplicity of the netpoll
> implementation is worth it given how problematic and hard to debug
> netpoll has been in the past.
>
>
There is a measurable difference in oprofile. When passing small
packets, there's a non-trivial difference in throughput.
^ permalink raw reply
* Re: [PATCH] TIPC: fix tipc_link_create error handling
From: David Miller @ 2007-07-26 7:05 UTC (permalink / raw)
To: fw; +Cc: netdev, allan.stephens, per.liden, jon.maloy, tipc-discussion
In-Reply-To: <20070724220256.GC8732@Chamillionaire.breakpoint.cc>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 25 Jul 2007 00:02:56 +0200
> if printbuf allocation or tipc_node_attach_link() fails, invalid
> references to the link are left in the associated node and bearer
> structures.
> Fix by allocating printbuf early and moving timer initialization
> and the addition of the new link to the b_ptr->links list after
> tipc_node_attach_link() succeeded.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Looks good Florian, patch applied, thanks.
^ permalink raw reply
* Re: [PATCH] kernel-doc fixes for net/
From: David Miller @ 2007-07-26 7:03 UTC (permalink / raw)
To: randy.dunlap; +Cc: netdev
In-Reply-To: <20070723214219.b50a0d1b.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 23 Jul 2007 21:42:19 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix kernel-doc omissions in net/:
>
> Warning(linux-2.6.23-rc1//net/core/dev.c:2728): No description found for parameter 'addr'
> Warning(linux-2.6.23-rc1//net/core/dev.c:2752): No description found for parameter 'addr'
> Warning(linux-2.6.23-rc1//net/core/dev.c:3839): No description found for parameter 'net_dma'
> Warning(linux-2.6.23-rc1//net/core/dev.c:3877): No description found for parameter 'state'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH 3/4 -rev1] Initilize and populate age field
From: Varun Chandramohan @ 2007-07-26 6:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, kaber, socketcan, shemminger, krkumar2
In-Reply-To: <46A84128.1090207@cosmosbay.com>
Eric Dumazet wrote:
> Varun Chandramohan a écrit :
>> Eric Dumazet wrote:
>>> Varun Chandramohan a écrit :
>>>> The age field is filled with the current time at the time of creation
>>>> of the route. When the routes are dumped
>>>> then the age value stored in the route structure is subtracted from
>>>> the current time value and the difference is the age expressed in
>>>> secs.
>>>>
>>>> }
>>>> +
>>>> + do_gettimeofday(&tv);
>>>> + if (!*age) {
>>>> + *age = timeval_to_sec(&tv);
>>>> + NLA_PUT_U32(skb, RTA_AGE, *age);
>>> here, what happens if sizeof(time_t) is not 4 ?
>>>
>> Same case as above :-) comments?
>
> So you are confident it (truncation from 8 to 4 bytes) works well on
> Big endian arches as well as Little endian arches ? :-)
>
I suppose so. But i must admit i have'nt tested it on Big endian arch
though!!!
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFC]: napi_struct V4
From: David Miller @ 2007-07-26 6:43 UTC (permalink / raw)
To: mchan; +Cc: netdev, shemminger, jgarzik, hadi, rusty
In-Reply-To: <1551EAE59135BE47B544934E30FC4FC002AAB9F7@nt-irva-0751.brcm.ad.broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 25 Jul 2007 23:39:18 -0700
> David Miller wrote:
>
> > As a result there is no more messing around with fake NAPI polls and
> > all that other crap, instead ->poll_controller() merely has to try to
> > process TX queue acks to free up space and wake up the transmit
> > queue(s) of the device.
> >
>
> I think we also need to take care of link change interrupts as well.
Since netpoll is best-effort, we can elide that I think.
The more requirements you put into this ->poll_controller()
handler, the more complicated it gets.
Furthermore, this should work out. If the link is down, the top level
poll loop will timeout waiting for the TX queue to open up, which will
kick the netpoll processing into a work queue, the link handling will
be allowed to occur meanwhile.
^ permalink raw reply
* Re: [PATCH RFC]: napi_struct V4
From: Michael Chan @ 2007-07-26 6:39 UTC (permalink / raw)
To: David Miller, netdev; +Cc: shemminger, jgarzik, hadi, rusty
In-Reply-To: <20070725.210943.122860438.davem@davemloft.net>
David Miller wrote:
> As a result there is no more messing around with fake NAPI polls and
> all that other crap, instead ->poll_controller() merely has to try to
> process TX queue acks to free up space and wake up the transmit
> queue(s) of the device.
>
I think we also need to take care of link change interrupts as well.
^ permalink raw reply
* Re: [PATCH 3/4 -rev1] Initilize and populate age field
From: Eric Dumazet @ 2007-07-26 6:37 UTC (permalink / raw)
To: Varun Chandramohan; +Cc: davem, netdev, kaber, socketcan, shemminger, krkumar2
In-Reply-To: <46A83EB9.6070903@linux.vnet.ibm.com>
Varun Chandramohan a écrit :
> Eric Dumazet wrote:
>> Varun Chandramohan a écrit :
>>> The age field is filled with the current time at the time of creation
>>> of the route. When the routes are dumped
>>> then the age value stored in the route structure is subtracted from
>>> the current time value and the difference is the age expressed in secs.
>>>
>>> }
>>> +
>>> + do_gettimeofday(&tv);
>>> + if (!*age) {
>>> + *age = timeval_to_sec(&tv);
>>> + NLA_PUT_U32(skb, RTA_AGE, *age);
>> here, what happens if sizeof(time_t) is not 4 ?
>>
> Same case as above :-) comments?
So you are confident it (truncation from 8 to 4 bytes) works well on Big
endian arches as well as Little endian arches ? :-)
^ permalink raw reply
* Re: [PATCH RFC]: napi_struct V4
From: David Miller @ 2007-07-26 6:38 UTC (permalink / raw)
To: mchan; +Cc: netdev, shemminger, jgarzik, hadi, rusty
In-Reply-To: <1551EAE59135BE47B544934E30FC4FC002AAB9F6@nt-irva-0751.brcm.ad.broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 25 Jul 2007 23:33:03 -0700
> This will lead to more and longer lock contentions between
> ->hard_start_xmit() and ->poll() in the normal fast path. Why
> do we need to widen the scope of netif_tx_lock() in this case?
So that ->poll_controller() can process TX acks by just having
the TX lock and interrupts disabled.
Can you think of another way to process TX acks from absolutely
any execution context whatsoever? That's what we need and
preferably in some generic way, and the above is what I came
up with.
To be honest I don't think the TX lock contention will matter, and
even if there were a small cost, the simplicity of the netpoll
implementation is worth it given how problematic and hard to debug
netpoll has been in the past.
^ permalink raw reply
* Re: [PATCH RFC]: napi_struct V4
From: Michael Chan @ 2007-07-26 6:33 UTC (permalink / raw)
To: David Miller, netdev; +Cc: shemminger, jgarzik, hadi, rusty
In-Reply-To: <20070725.210943.122860438.davem@davemloft.net>
David Miller wrote:
> /* run TX completion thread */
> if (sblk->idx[0].tx_consumer != tp->tx_cons) {
> - tg3_tx(tp);
> + netif_tx_lock(netdev);
> + __tg3_tx(tp);
> + netif_tx_unlock(netdev);
>
This will lead to more and longer lock contentions between
->hard_start_xmit() and ->poll() in the normal fast path. Why
do we need to widen the scope of netif_tx_lock() in this case?
By not taking the netif_tx_lock() during tx completions until
the last moment and only when necessary improves the performance
substantially.
^ permalink raw reply
* Re: [PATCH 3/4 -rev1] Initilize and populate age field
From: Varun Chandramohan @ 2007-07-26 6:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, kaber, socketcan, shemminger, krkumar2
In-Reply-To: <46A8391C.2020605@cosmosbay.com>
Eric Dumazet wrote:
> Varun Chandramohan a écrit :
>> The age field is filled with the current time at the time of creation
>> of the route. When the routes are dumped
>> then the age value stored in the route structure is subtracted from
>> the current time value and the difference is the age expressed in secs.
>>
>> Signed-off-by: Varun Chandramohan <varunc@linux.vnet.ibm.com>
>> ---
>> net/ipv4/fib_hash.c | 3 +++
>> net/ipv4/fib_lookup.h | 3 ++-
>> net/ipv4/fib_semantics.c | 16 +++++++++++++---
>> net/ipv4/fib_trie.c | 1 +
>> 4 files changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/ipv4/fib_hash.c b/net/ipv4/fib_hash.c
>> index 07e843a..faa7364 100644
>> --- a/net/ipv4/fib_hash.c
>> +++ b/net/ipv4/fib_hash.c
>> @@ -448,6 +448,7 @@ static int fn_hash_insert(struct fib_tab
>> fa->fa_info = fi;
>> fa->fa_type = cfg->fc_type;
>> fa->fa_scope = cfg->fc_scope;
>> + fa->fa_age = 0;
>> state = fa->fa_state;
>> fa->fa_state &= ~FA_S_ACCESSED;
>> fib_hash_genid++;
>> @@ -507,6 +508,7 @@ static int fn_hash_insert(struct fib_tab
>> new_fa->fa_type = cfg->fc_type;
>> new_fa->fa_scope = cfg->fc_scope;
>> new_fa->fa_state = 0;
>> + new_fa->fa_age = 0;
>>
>> /*
>> * Insert new entry to the list.
>> @@ -697,6 +699,7 @@ fn_hash_dump_bucket(struct sk_buff *skb,
>> f->fn_key,
>> fz->fz_order,
>> fa->fa_tos,
>> + &fa->fa_age,
>> fa->fa_info,
>> NLM_F_MULTI) < 0) {
>> cb->args[4] = i;
>> diff --git a/net/ipv4/fib_lookup.h b/net/ipv4/fib_lookup.h
>> index eef9eec..c9145b5 100644
>> --- a/net/ipv4/fib_lookup.h
>> +++ b/net/ipv4/fib_lookup.h
>> @@ -13,6 +13,7 @@ struct fib_alias {
>> u8 fa_type;
>> u8 fa_scope;
>> u8 fa_state;
>> + time_t fa_age;
>> };
>>
>> #define FA_S_ACCESSED 0x01
>> @@ -27,7 +28,7 @@ extern struct fib_info *fib_create_info(
>> extern int fib_nh_match(struct fib_config *cfg, struct fib_info *fi);
>> extern int fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int
>> event,
>> u32 tb_id, u8 type, u8 scope, __be32 dst,
>> - int dst_len, u8 tos, struct fib_info *fi,
>> + int dst_len, u8 tos, time_t *age, struct fib_info *fi,
>> unsigned int);
>> extern void rtmsg_fib(int event, __be32 key, struct fib_alias *fa,
>> int dst_len, u32 tb_id, struct nl_info *info,
>> diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
>> index c434119..1822d92 100644
>> --- a/net/ipv4/fib_semantics.c
>> +++ b/net/ipv4/fib_semantics.c
>> @@ -278,7 +278,8 @@ static inline size_t fib_nlmsg_size(stru
>> + nla_total_size(4) /* RTA_TABLE */
>> + nla_total_size(4) /* RTA_DST */
>> + nla_total_size(4) /* RTA_PRIORITY */
>> - + nla_total_size(4); /* RTA_PREFSRC */
>> + + nla_total_size(4) /* RTA_PREFSRC */
>> + + nla_total_size(4); /*RTA_AGE*/
>
> Not clear to me what happens on platforms where sizeof(time_t) is 8
>
I was aware of this issue, but the reason we decided to go with 4 is
that netlink is defined for use across a network. Since the size of
time_t varies in different architecture, it would mean that a system
with size 4 may not be able to talk to system with size 8. So i made it
constant. So in the above case we round off to 4.
>
>>
>> /* space for nested metrics */
>> payload += nla_total_size((RTAX_MAX * nla_total_size(4)));
>> @@ -313,7 +314,7 @@ void rtmsg_fib(int event, __be32 key, st
>>
>> err = fib_dump_info(skb, info->pid, seq, event, tb_id,
>> fa->fa_type, fa->fa_scope, key, dst_len,
>> - fa->fa_tos, fa->fa_info, nlm_flags);
>> + fa->fa_tos, &fa->fa_age, fa->fa_info, nlm_flags);
>> if (err < 0) {
>> /* -EMSGSIZE implies BUG in fib_nlmsg_size() */
>> WARN_ON(err == -EMSGSIZE);
>> @@ -940,11 +941,12 @@ __be32 __fib_res_prefsrc(struct fib_resu
>> }
>>
>> int fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event,
>> - u32 tb_id, u8 type, u8 scope, __be32 dst, int dst_len, u8
>> tos,
>> + u32 tb_id, u8 type, u8 scope, __be32 dst, int dst_len, u8
>> tos, time_t *age,
>> struct fib_info *fi, unsigned int flags)
>> {
>> struct nlmsghdr *nlh;
>> struct rtmsg *rtm;
>> + struct timeval tv;
>>
>> nlh = nlmsg_put(skb, pid, seq, event, sizeof(*rtm), flags);
>> if (nlh == NULL)
>> @@ -985,6 +987,14 @@ int fib_dump_info(struct sk_buff *skb, u
>> NLA_PUT_U32(skb, RTA_FLOW, fi->fib_nh[0].nh_tclassid);
>> #endif
>> }
>> +
>> + do_gettimeofday(&tv);
>> + if (!*age) {
>> + *age = timeval_to_sec(&tv);
>> + NLA_PUT_U32(skb, RTA_AGE, *age);
>
> here, what happens if sizeof(time_t) is not 4 ?
>
Same case as above :-) comments?
>> + } else {
>> + NLA_PUT_U32(skb, RTA_AGE, timeval_to_sec(&tv) - *age);
>> + }
>> #ifdef CONFIG_IP_ROUTE_MULTIPATH
>> if (fi->fib_nhs > 1) {
>> struct rtnexthop *rtnh;
>> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
>> index 30e332a..be2d1d6 100644
>> --- a/net/ipv4/fib_trie.c
>> +++ b/net/ipv4/fib_trie.c
>> @@ -1884,6 +1884,7 @@ static int fn_trie_dump_fa(t_key key, in
>> xkey,
>> plen,
>> fa->fa_tos,
>> + &fa->fa_age,
>> fa->fa_info, 0) < 0) {
>> cb->args[4] = i;
>> return -1;
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/4 -rev1] Add new timeval_to_sec function
From: Oliver Hartkopp @ 2007-07-26 6:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: Varun Chandramohan, davem, netdev, kaber, socketcan, shemminger,
krkumar2
In-Reply-To: <46A837FE.5060900@cosmosbay.com>
Eric Dumazet wrote:
> Varun Chandramohan a écrit :
>>
>> + return (tv->tv_sec + (tv->tv_usec + 999999)/1000000);
>
> return tv->tv_sec + (tv->tv_usec ? 1 : 0);
>
> is much faster
It additionally wins the design award in opposite to my suggestion ;-)
Thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox