* Re: e1000_down and tx_timeout worker race cleaning the transmit buffers
From: Herbert Xu @ 2006-04-21 2:40 UTC (permalink / raw)
To: Michael Chan; +Cc: shawvrana, netdev, auke-jan.h.kok, davem, jgarzik
In-Reply-To: <E1FWlWa-0007hN-00@gondolin.me.apana.org.au>
On Fri, Apr 21, 2006 at 12:37:36PM +1000, Herbert Xu wrote:
>
> Rather than dealing with this individually in each driver perhaps we should
> come up with a more centralised solution?
One simple solution is to establish a separate queue for RTNL-holding
users or vice versa for non-RTNL holding networking users. That
would allow the drivers to safely flush the non-RTNL queue while
holding the RTNL.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: e1000_down and tx_timeout worker race cleaning the transmit buffers
From: Shaw Vrana @ 2006-04-21 2:42 UTC (permalink / raw)
To: Michael Chan; +Cc: Herbert Xu, shawvrana, netdev, Auke Kok, David S. Miller
In-Reply-To: <1145578214.3195.6.camel@rh4>
[-- Attachment #1: Type: text/plain, Size: 441 bytes --]
On Thursday 20 April 2006 17:10, Michael Chan wrote:
> In tg3_remove_one(), we call flush_scheduled_work() in case the
> reset_task is still pending. Here, it is safe to call
> flush_scheduled_work() because we're not holding the rtnl. Again, when
> it runs, nothing bad will happen because it will see netif_running() ==
> 0.
I'll bite! Here's a patch to add a call to flush_scheduled_work() in
e1000_down. It's against 2.6.16.9.
Shaw
[-- Attachment #2: e1000_flush_in_close.patch --]
[-- Type: text/x-diff, Size: 614 bytes --]
diff -u -uprN -X linux-2.6.16.9/Documentation/dontdiff linux-2.6.16.9/drivers/net/e1000/e1000_main.c linux-2.6.16.9-patch/drivers/net/e1000/e1000_main.c
--- linux-2.6.16.9/drivers/net/e1000/e1000_main.c 2006-04-18 23:10:14.000000000 -0700
+++ linux-2.6.16.9-patch/drivers/net/e1000/e1000_main.c 2006-04-20 19:36:55.000000000 -0700
@@ -538,6 +538,7 @@ e1000_down(struct e1000_adapter *adapter
del_timer_sync(&adapter->tx_fifo_stall_timer);
del_timer_sync(&adapter->watchdog_timer);
del_timer_sync(&adapter->phy_info_timer);
+ flush_scheduled_work();
#ifdef CONFIG_E1000_NAPI
netif_poll_disable(netdev);
^ permalink raw reply
* Re: Cannot receive multicast packets
From: David Stevens @ 2006-04-21 3:05 UTC (permalink / raw)
To: Andrew Athan; +Cc: netdev
In-Reply-To: <44482C8D.7010401@cloakmail.com>
Andrew,
> I did not
> think the source IP was relevant to the matching code in linux, since
> there are no source squelching socket options.
>
> There are no firewall rules active on this machine, and the packets are
> definitely visible at the interface (see tcpdump output in my email).
The source address is not relevant (other than potentially
for firewall rules), and I understand from your original mail that
they are arriving at the machine. The IP TTL is what I wanted to
know there; but "netstat -s" will normally tell you why a packet
was dropped, if it's arriving but not making it through the UDP/IP
stack (as is your case).
> I am going to try upgrading the kernel, and turning off the multicast
> router kernel options as a next step. But if you have any other ideas
> at all, I'm all ears.
"netstat -s" would be a good start. :-) tcpdump receiving a copy
of the packet does not mean UDP or IP won't drop it, but those drops
are counted.
+-DLS
^ permalink raw reply
* Re: e1000_down and tx_timeout worker race cleaning the transmit buffers
From: Michael Chan @ 2006-04-21 1:24 UTC (permalink / raw)
To: Herbert Xu; +Cc: shawvrana, netdev, auke-jan.h.kok, davem, jgarzik
In-Reply-To: <20060421024024.GA29644@gondor.apana.org.au>
On Fri, 2006-04-21 at 12:40 +1000, Herbert Xu wrote:
> One simple solution is to establish a separate queue for RTNL-holding
> users or vice versa for non-RTNL holding networking users. That
> would allow the drivers to safely flush the non-RTNL queue while
> holding the RTNL.
You mean a separate workqueue for net drivers to use instead of the
keventd_wq? Yeah, I think that'll work. Each driver can also create its
own workqueue but that may be a bit more wasteful.
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: Olof Johansson @ 2006-04-21 3:04 UTC (permalink / raw)
To: David S. Miller; +Cc: olof, andrew.grover, netdev
In-Reply-To: <20060420.172742.132879746.davem@davemloft.net>
On Thu, Apr 20, 2006 at 05:27:42PM -0700, David S. Miller wrote:
> From: Olof Johansson <olof@lixom.net>
> Date: Thu, 20 Apr 2006 16:33:05 -0500
>
> > From the wiki:
> >
> > > 3. Data copied by I/OAT is not cached
> >
> > This is a I/OAT device limitation and not a global statement of the
> > DMA infrastructure. Other platforms might be able to prime caches
> > with the DMA traffic. Hint flags should be added on either the channel
> > allocation calls, or per-operation calls, depending on where it makes
> > sense driver/client wise.
>
> This sidesteps the whole question of _which_ cache to warm. And if
> you choose wrongly, then what?
>
> Besides the control overhead of the DMA engines, the biggest thing
> lost in my opinion is the perfect cache warming that a cpu based copy
> does from the kernel socket buffer into userspace.
It's definitely the easiest way to always make sure the right caches
are warm for the app, that I agree with.
But, when warming those caches by copying, the data is pulled in through
a potentially cold cache in the first place. So the cache misses are
just moved from the copy loop to userspace with dma offload. Or am I
missing something?
> The first thing an application is going to do is touch that data. So
> I think it's very important to prewarm the caches and the only
> straightforward way I know of to always warm up the correct cpu's
> caches is copy_to_user().
The other way (assuming the hardware supports cache warming) would be
to pass down affinities (or look them up during receive processing,
I'm not sure that's practical the way things work now), and dispatch
on a DMA channel with the right cache affinity. I've got a feeling that
"straightforward" is not a term to use for describing that solution
though.
> Unfortunately, many benchmarks just do raw bandwidth tests sending to
> a receiver that just doesn't even look at the data. They just return
> from recvmsg() and loop back into it. This is not what applications
> using networking actually do, so it's important to make sure we look
> intelligently at any benchmarks done and do not fall into the trap of
> saying "even without cache warming it made things faster" when in fact
> the tested receiver did not touch the data at all so was a false test.
Yes, some real-life-like benchmarking is definitiely needed. Unfortunately
I'm not at a position where I can do much (and share numbers) at the
moment myself.
-Olof
^ permalink raw reply
* Re: e1000_down and tx_timeout worker race cleaning the transmit buffers
From: shaw @ 2006-04-21 3:05 UTC (permalink / raw)
To: Michael Chan; +Cc: Herbert Xu, shawvrana, netdev, Auke Kok, David S. Miller
In-Reply-To: <1145578214.3195.6.camel@rh4>
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
I've replied to this once before, but haven't seen my last two emails on the
list, so I'm sending again with different settings. Sorry for the noise.
On Thursday 20 April 2006 17:10, Michael Chan wrote:
> In tg3_remove_one(), we call flush_scheduled_work() in case the
> reset_task is still pending. Here, it is safe to call
> flush_scheduled_work() because we're not holding the rtnl. Again, when
> it runs, nothing bad will happen because it will see netif_running() ==
> 0.
I'll bite! Here's a patch to add a call to flush_scheduled_work() in
e1000_down. It's against 2.6.16.9.
Thanks,
Shaw
[-- Attachment #2: e1000_flush_in_close.patch --]
[-- Type: text/x-diff, Size: 614 bytes --]
diff -u -uprN -X linux-2.6.16.9/Documentation/dontdiff linux-2.6.16.9/drivers/net/e1000/e1000_main.c linux-2.6.16.9-patch/drivers/net/e1000/e1000_main.c
--- linux-2.6.16.9/drivers/net/e1000/e1000_main.c 2006-04-18 23:10:14.000000000 -0700
+++ linux-2.6.16.9-patch/drivers/net/e1000/e1000_main.c 2006-04-20 19:36:55.000000000 -0700
@@ -538,6 +538,7 @@ e1000_down(struct e1000_adapter *adapter
del_timer_sync(&adapter->tx_fifo_stall_timer);
del_timer_sync(&adapter->watchdog_timer);
del_timer_sync(&adapter->phy_info_timer);
+ flush_scheduled_work();
#ifdef CONFIG_E1000_NAPI
netif_poll_disable(netdev);
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: Olof Johansson @ 2006-04-21 3:09 UTC (permalink / raw)
To: David S. Miller; +Cc: andy.grover, netdev
In-Reply-To: <20060420.174438.15249396.davem@davemloft.net>
On Thu, Apr 20, 2006 at 05:44:38PM -0700, David S. Miller wrote:
> From: Olof Johansson <olof@lixom.net>
> Date: Thu, 20 Apr 2006 18:33:43 -0500
>
> > On Thu, Apr 20, 2006 at 03:14:15PM -0700, Andrew Grover wrote:
> > > In
> > > addition, there may be workloads (file serving? backup?) where we
> > > could do a skb->page-in-page-cache copy and avoid cache pollution?
> >
> > Yes, NFS is probably a prime example of where most of the data isn't
> > looked at; just written to disk. I'm not sure how well-optimized the
> > receive path is there already w.r.t. avoiding copying though. I don't
> > remember seeing memcpy and friends being high on the profile when I
> > looked at SPECsfs last.
>
> If that makes sense then the cpu copy can be made to use non-temporal
> stores.
I'm not sure that would buy anything. I didn't mean caching was
necessarily bad, just that lack of it might not hurt as much under that
specific type of workload.
NFS has to look at RPC/NFS headers anyway, so it will benefit from the
cache being warm.
-Olof
^ permalink raw reply
* Re: e1000_down and tx_timeout worker race cleaning the transmit buffers
From: Michael Chan @ 2006-04-21 1:33 UTC (permalink / raw)
To: Shaw Vrana; +Cc: Herbert Xu, netdev, Auke Kok, David S. Miller
In-Reply-To: <200604201942.07009.shawvrana@acm.org>
On Thu, 2006-04-20 at 19:42 -0700, Shaw Vrana wrote:
> I'll bite! Here's a patch to add a call to flush_scheduled_work() in
> e1000_down. It's against 2.6.16.9.
>
You're not following our discussion. It is not safe to call
flush_scheduled_work() in a driver's close() because it is holding the
rtnl and can deadlock with linkwatch_event() if it happens to be on the
workqueue.
^ permalink raw reply
* [PATCH] Unregister network device before releasing PCMCIA resources
From: Pavel Roskin @ 2006-04-21 3:17 UTC (permalink / raw)
To: netdev; +Cc: linux-pcmcia, linville, Dominik Brodowski
From: Pavel Roskin <proski@gnu.org>
This is the right thing to do and it prevents kernel BUG on unload.
Some PCMCIA network drivers use link->dev_node as a flag indicating that
the network device has been successfully registered. Recent code
changes cause this flag to be 0 after PCMCIA resources have been
released.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
drivers/net/wireless/netwave_cs.c | 4 ++--
drivers/net/wireless/orinoco_cs.c | 5 +++--
drivers/net/wireless/ray_cs.c | 4 +++-
drivers/net/wireless/spectrum_cs.c | 5 +++--
drivers/net/wireless/wavelan_cs.c | 9 +++++----
5 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/netwave_cs.c b/drivers/net/wireless/netwave_cs.c
index 9343d97..5d80db2 100644
--- a/drivers/net/wireless/netwave_cs.c
+++ b/drivers/net/wireless/netwave_cs.c
@@ -445,11 +445,11 @@ static void netwave_detach(struct pcmcia
DEBUG(0, "netwave_detach(0x%p)\n", link);
- netwave_release(link);
-
if (link->dev_node)
unregister_netdev(dev);
+ netwave_release(link);
+
free_netdev(dev);
} /* netwave_detach */
diff --git a/drivers/net/wireless/orinoco_cs.c b/drivers/net/wireless/orinoco_cs.c
index 434f7d7..5988305 100644
--- a/drivers/net/wireless/orinoco_cs.c
+++ b/drivers/net/wireless/orinoco_cs.c
@@ -147,14 +147,15 @@ static void orinoco_cs_detach(struct pcm
{
struct net_device *dev = link->priv;
- orinoco_cs_release(link);
-
DEBUG(0, PFX "detach: link=%p link->dev_node=%p\n", link, link->dev_node);
if (link->dev_node) {
DEBUG(0, PFX "About to unregister net device %p\n",
dev);
unregister_netdev(dev);
}
+
+ orinoco_cs_release(link);
+
free_orinocodev(dev);
} /* orinoco_cs_detach */
diff --git a/drivers/net/wireless/ray_cs.c b/drivers/net/wireless/ray_cs.c
index 879eb42..fac4f1b 100644
--- a/drivers/net/wireless/ray_cs.c
+++ b/drivers/net/wireless/ray_cs.c
@@ -388,13 +388,15 @@ static void ray_detach(struct pcmcia_dev
this_device = NULL;
dev = link->priv;
+ if (link->dev_node)
+ unregister_netdev(dev);
+
ray_release(link);
local = (ray_dev_t *)dev->priv;
del_timer(&local->timer);
if (link->priv) {
- if (link->dev_node) unregister_netdev(dev);
free_netdev(dev);
}
DEBUG(2,"ray_cs ray_detach ending\n");
diff --git a/drivers/net/wireless/spectrum_cs.c b/drivers/net/wireless/spectrum_cs.c
index f7b77ce..2551938 100644
--- a/drivers/net/wireless/spectrum_cs.c
+++ b/drivers/net/wireless/spectrum_cs.c
@@ -626,14 +626,15 @@ static void spectrum_cs_detach(struct pc
{
struct net_device *dev = link->priv;
- spectrum_cs_release(link);
-
DEBUG(0, PFX "detach: link=%p link->dev_node=%p\n", link, link->dev_node);
if (link->dev_node) {
DEBUG(0, PFX "About to unregister net device %p\n",
dev);
unregister_netdev(dev);
}
+
+ spectrum_cs_release(link);
+
free_orinocodev(dev);
} /* spectrum_cs_detach */
diff --git a/drivers/net/wireless/wavelan_cs.c b/drivers/net/wireless/wavelan_cs.c
index f7724eb..03c2e16 100644
--- a/drivers/net/wireless/wavelan_cs.c
+++ b/drivers/net/wireless/wavelan_cs.c
@@ -4681,6 +4681,11 @@ #ifdef DEBUG_CALLBACK_TRACE
printk(KERN_DEBUG "-> wavelan_detach(0x%p)\n", link);
#endif
+ /* Remove ourselves from the kernel list of ethernet devices */
+ /* Warning : can't be called from interrupt, timer or wavelan_close() */
+ if (link->dev_node)
+ unregister_netdev(dev);
+
/* Some others haven't done their job : give them another chance */
wv_pcmcia_release(link);
@@ -4689,10 +4694,6 @@ #endif
{
struct net_device * dev = (struct net_device *) link->priv;
- /* Remove ourselves from the kernel list of ethernet devices */
- /* Warning : can't be called from interrupt, timer or wavelan_close() */
- if (link->dev_node)
- unregister_netdev(dev);
link->dev_node = NULL;
((net_local *)netdev_priv(dev))->link = NULL;
((net_local *)netdev_priv(dev))->dev = NULL;
^ permalink raw reply related
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: David S. Miller @ 2006-04-21 3:42 UTC (permalink / raw)
To: olof; +Cc: andrew.grover, netdev
In-Reply-To: <20060421030426.GM26746@pb15.lixom.net>
From: Olof Johansson <olof@lixom.net>
Date: Thu, 20 Apr 2006 22:04:26 -0500
> On Thu, Apr 20, 2006 at 05:27:42PM -0700, David S. Miller wrote:
> > Besides the control overhead of the DMA engines, the biggest thing
> > lost in my opinion is the perfect cache warming that a cpu based copy
> > does from the kernel socket buffer into userspace.
>
> It's definitely the easiest way to always make sure the right caches
> are warm for the app, that I agree with.
>
> But, when warming those caches by copying, the data is pulled in through
> a potentially cold cache in the first place. So the cache misses are
> just moved from the copy loop to userspace with dma offload. Or am I
> missing something?
Yes, and it means that the memory bandwidth costs are equivalent
between I/O AT and cpu copy.
In the cpu copy case you eat the read cache miss, but on the write
side you'll prewarm the cache properly. In the I/O AT case you
eat the same read cost, but the cache will not be prewarmed, so you'll
eat the read cache miss in the application. It's moving the same
exact cost from one place to another.
The time it takes to get the app to make forward progress (meaning
returned from the recvmsg() system call and back in userspace) must by
definition take at least as long with I/O AT as it does with cpu
copies. Yet in the I/O AT case, the application must wait that long
and also then take in the delays of the cache misses when it tries to
read the data that the I/O AT engine copied. Instead of eating the
cache miss cost in the kernel, we eat it in the app because in the I/O
AT case the cpu won't have the user data fresh and loaded into the cpu
cache.
And I say I/O AT must take "at least as long" as cpu copies because
the same memory copy cost is there, and on top of that I/O AT has to
program the DMA controller and touch a _lot_ of other state to get
things going and then wake the task up. We're talking non-trivial
overheads like grabbing the page mappings out of the page tables using
get_user_pages(). Evgivny has posted some very nice performance graphs
showing how poorly that function scales.
This is basically why none of the performance gains add up to me. I
am thus very concerned that the current non-cache-warming
implmentation may fall flat performance wise.
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: Olof Johansson @ 2006-04-21 4:42 UTC (permalink / raw)
To: David S. Miller; +Cc: olof, andrew.grover, netdev
In-Reply-To: <20060420.204200.103377406.davem@davemloft.net>
On Thu, Apr 20, 2006 at 08:42:00PM -0700, David S. Miller wrote:
> This is basically why none of the performance gains add up to me. I
> am thus very concerned that the current non-cache-warming
> implmentation may fall flat performance wise.
Ok, I buy your arguments. It does seems unlikely that a DMA offload
without cache warmth will be a net gain. More performance data is
definitely be required.
After digging after PDFs, it seems as the Freescale 85xx (at least,
probably earlier models as well) can warm L2 for the DMA destination
data. However, I don't have any hardware with it to play around
with for benchmarking to see what cache warming might bring (back),
performance-wise.
I think there is still use for a common multi-function DMA framework
across platforms and client components, even if net receive doesn't end
up being {a,the first} user.
-Olof
^ permalink raw reply
* Congestion Avoidance Monitoring Tools
From: Piet Delaney @ 2006-04-21 5:26 UTC (permalink / raw)
To: netdev; +Cc: Piet Delaney, linux-net
I'm upgrading our 2.6.12 kernel to 2.6.13, which includes significant
congestion avoidance code additions and changes. I was wondering if
there are any tools folks can recommend for testing the kernel to make
sure the congestion avoidance code is operating correctly. For
example the displaying of the congestion window as a function of time
while undergoing convergence. For causing congestion I could modify
a kernel to discard packets once in a while on a lab gateway and hit
it with iperf. HP's netperf looks interesting.
Any suggestions?
-piet
--
---
piet@bluelane.com
^ permalink raw reply
* Fw: [Bugme-new] [Bug 6420] New: iptables is complaining with bogus unknown error 18446744073709551615
From: Andrew Morton @ 2006-04-21 6:26 UTC (permalink / raw)
To: netdev; +Cc: mvolaski, bugme-daemon@kernel-bugs.osdl.org
Begin forwarded message:
Date: Thu, 20 Apr 2006 23:17:58 -0700
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 6420] New: iptables is complaining with bogus unknown error 18446744073709551615
http://bugzilla.kernel.org/show_bug.cgi?id=6420
Summary: iptables is complaining with bogus unknown error
18446744073709551615
Kernel Version: 2.6.17-rc2
Status: NEW
Severity: normal
Owner: laforge@gnumonks.org
Submitter: mvolaski@aecom.yu.edu
At least since 2.6.1.16.1, many calls to iptables no longer function at least
under 64-bit x86, presumably due to a bug in the netfilter kernel code.
The problem is still present in 2.6.17-rc2.
The error from iptables is
iptables: unknown error 18446744073709551615
Examples of rules that give the error are
1) iptables -A INPUT -i bond0 -s 129.98.90.0/24 -p tcp --dport 548 -j ACCEPT
2) iptables -A INPUT -i bond0 -s 129.98.90.101/32 -p tcp --dport 497 -j ACCEPT
3) iptables -A INPUT -i bond0 -s 129.98.90.227/32 -p tcp --dport 22 -j ACCEPT
Example of a rule that does not give the error:
1) iptables -A INPUT -i bond0 -p ICMP --icmp-type echo-request -s
129.98.90.13/32 -j ACCEPT
The computer is using IPv4 and not IPv6, which has not been compiled into the
kernel.
iptables is version 1.3.5.
Kernel configuration related to iptables follows:
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
CONFIG_IP_NF_CONNTRACK_EVENTS=y
CONFIG_IP_NF_CONNTRACK_NETLINK=m
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=m
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_NETBIOS_NS is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_PPTP is not set
# CONFIG_IP_NF_H323 is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_HASHLIMIT=m
CONFIG_IP_NF_FILTER=m
# CONFIG_IP_NF_TARGET_REJECT is not set
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
# CONFIG_IP_NF_NAT is not set
CONFIG_IP_NF_MANGLE=m
# CONFIG_IP_NF_TARGET_TOS is not set
# CONFIG_IP_NF_TARGET_ECN is not set
# CONFIG_IP_NF_TARGET_DSCP is not set
# CONFIG_IP_NF_TARGET_TTL is not set
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
# CONFIG_NETFILTER_XT_TARGET_CONNMARK is not set
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
# CONFIG_NETFILTER_XT_TARGET_NOTRACK is not set
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
lsmod shows
xt_state 4928 0
ipt_LOG 8960 0
ip_conntrack_ftp 10000 0
ip_conntrack 57880 2 xt_state,ip_conntrack_ftp
nfnetlink 8520 1 ip_conntrack
iptable_filter 5440 0
ip_tables 22168 1 iptable_filter
x_tables 17800 3 xt_state,ipt_LOG,ip_tables
This issue has been posted to netfilter bugzilla as
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=467
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply
* Re: Congestion Avoidance Monitoring Tools
From: Tom Young @ 2006-04-21 5:59 UTC (permalink / raw)
To: piet; +Cc: netdev, linux-net
In-Reply-To: <1145597174.12413.17.camel@piet2.bluelane.com>
On Thu, 2006-04-20 at 22:26 -0700, Piet Delaney wrote:
> I'm upgrading our 2.6.12 kernel to 2.6.13, which includes significant
> congestion avoidance code additions and changes. I was wondering if
> there are any tools folks can recommend for testing the kernel to make
> sure the congestion avoidance code is operating correctly. For
> example the displaying of the congestion window as a function of time
> while undergoing convergence. For causing congestion I could modify
> a kernel to discard packets once in a while on a lab gateway and hit
> it with iperf. HP's netperf looks interesting.
>
> Any suggestions?
>
>
> -piet
>
Hi,
Try having a look at the output of 'ss -i' (you may need to update to
the latest iproute2 tools). You could either try and parse the text
output of that or use the same inet_diag interface that ss uses to poll
for the data it at regular intervals.
--
Thomas Young
http://cubinlab.ee.unimelb.edu.au/~tyo/
Research Assistant
CUBIN Research Centre - University of Melbourne
^ permalink raw reply
* Re: Congestion Avoidance Monitoring Tools
From: Andi Kleen @ 2006-04-21 6:57 UTC (permalink / raw)
To: Tom Young; +Cc: piet, netdev, linux-net
In-Reply-To: <1145599196.2534.38.camel@penguin>
On Friday 21 April 2006 07:59, Tom Young wrote:
> On Thu, 2006-04-20 at 22:26 -0700, Piet Delaney wrote:
> > I'm upgrading our 2.6.12 kernel to 2.6.13, which includes significant
> > congestion avoidance code additions and changes. I was wondering if
> > there are any tools folks can recommend for testing the kernel to make
> > sure the congestion avoidance code is operating correctly. For
> > example the displaying of the congestion window as a function of time
> > while undergoing convergence. For causing congestion I could modify
> > a kernel to discard packets once in a while on a lab gateway and hit
> > it with iperf. HP's netperf looks interesting.
> >
> > Any suggestions?
> >
> >
> > -piet
> >
>
> Hi,
>
> Try having a look at the output of 'ss -i' (you may need to update to
> the latest iproute2 tools). You could either try and parse the text
> output of that or use the same inet_diag interface that ss uses to poll
> for the data it at regular intervals.
Another way is to use tcptrace on a tcpdump file
(http://jarok.cs.ohiou.edu/software/tcptrace/)
It finds a lot of statistics about the dumped TCP connections.
Newer ethereal also has some TCP plotting functions that are useful.
They don't display the congestion window directly, but you can see it indirectly.
-Andi
^ permalink raw reply
* Re: Congestion Avoidance Monitoring Tools
From: Piet Delaney @ 2006-04-21 7:25 UTC (permalink / raw)
To: Andi Kleen; +Cc: Piet Delaney, Tom Young, netdev, linux-net
In-Reply-To: <200604210857.19084.ak@suse.de>
On Fri, 2006-04-21 at 08:57 +0200, Andi Kleen wrote:
> On Friday 21 April 2006 07:59, Tom Young wrote:
> > On Thu, 2006-04-20 at 22:26 -0700, Piet Delaney wrote:
> > > I'm upgrading our 2.6.12 kernel to 2.6.13, which includes significant
> > > congestion avoidance code additions and changes. I was wondering if
> > > there are any tools folks can recommend for testing the kernel to make
> > > sure the congestion avoidance code is operating correctly. For
> > > example the displaying of the congestion window as a function of time
> > > while undergoing convergence. For causing congestion I could modify
> > > a kernel to discard packets once in a while on a lab gateway and hit
> > > it with iperf. HP's netperf looks interesting.
> > >
> > > Any suggestions?
> > >
> > >
> > > -piet
> > >
> >
> > Hi,
> >
> > Try having a look at the output of 'ss -i' (you may need to update to
> > the latest iproute2 tools). You could either try and parse the text
> > output of that or use the same inet_diag interface that ss uses to poll
> > for the data it at regular intervals.
>
> Another way is to use tcptrace on a tcpdump file
> (http://jarok.cs.ohiou.edu/software/tcptrace/)
> It finds a lot of statistics about the dumped TCP connections.
Tcptrace looks pretty good, graphing the sequence numbers as a function
of time was one of the features I'm looking for.
>
> Newer ethereal also has some TCP plotting functions that are useful.
> They don't display the congestion window directly, but you can see it indirectly.
I never tried the ethereal graph facility, looks like another great
idea.
Thanks,
-piet
>
> -Andi
--
---
piet@bluelane.com
^ permalink raw reply
* Fw: Bug: PPP dropouts in >=2.6.16
From: Andrew Morton @ 2006-04-21 8:08 UTC (permalink / raw)
To: netdev; +Cc: Nuri Jawad
We do seem to have had a few reports of ppp regressions around this
timeframe.
Begin forwarded message:
Date: Thu, 20 Apr 2006 23:28:24 +0200 (CEST)
From: Nuri Jawad <lkml@jawad.org>
To: linux-kernel@vger.kernel.org
Subject: Bug: PPP dropouts in >=2.6.16
Good evening,
I've recently had problems with my ADSL connection (PPPoE) after upgrading
from 2.6.15.3 to 2.6.16.5. Every now and then, it would stall for 30-50
seconds. According to tcpdump, during these dropouts packets get received
through ppp0 but none that are supposed to be sent appear on the
interface. This is consistent with the modem not sending out any data via
its ATM interface during these periods. I made sure the ISP, modem or
ethernet interface wasn't the problem with a second box running IPCop
(minimal 2.4 router distro, I can log in twice with my ISP) and a telnet
connection to the modem that never stalled.
Upgrading pppd from 2.4.2 to 2.4.4b1 and rp-pppoe from 3.5 (latest Debian
package) to 3.8 had no effect.
I was using Bittorrent and also the folding@home client so the system had
a high load. Stopping those seemed to reduce the frequency of dropouts
but they were still coming up at least every few hours. A fallback to the
old kernel made the problem disappear.
I then tested 24 hours a day this week by pinging my box from 2 hosts and
making sure above load was persistent, while trying different kernels. So
far I can say that:
- <= 2.6.15.7 is not affected, tested with .3, .4 and .7
- >= 2.6.16 is affected, tested with 2.6.16, .1, .5 and .9
- the dropouts last between 30 and 50 seconds but often exactly 41, they
appear about every half to one hour
- a night yields 20-40 lost packets with 2.6.15 and 700-1100 with 2.6.16
on my connection
The system:
P4 Northwood with HT enabled, 2 GB RAM, Asus P4C800
Boot/root PATA ICH5, torrents saved to SATA HD through ata-piix
Third drive through sata-promise
Debian GNU/Linux unstable
Kernel config: http://jawad.org/.config
Let me know what I can do to give you more specific information.
Regards,
Nuri
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: e1000_down and tx_timeout worker race cleaning the transmit buffers
From: Andy Gospodarek @ 2006-04-21 13:27 UTC (permalink / raw)
To: Michael Chan
Cc: Herbert Xu, shawvrana, netdev, auke-jan.h.kok, davem, jgarzik
In-Reply-To: <1145582676.3195.18.camel@rh4>
On Thu, Apr 20, 2006 at 06:24:36PM -0700, Michael Chan wrote:
> On Fri, 2006-04-21 at 12:40 +1000, Herbert Xu wrote:
>
> > One simple solution is to establish a separate queue for RTNL-holding
> > users or vice versa for non-RTNL holding networking users. That
> > would allow the drivers to safely flush the non-RTNL queue while
> > holding the RTNL.
>
> You mean a separate workqueue for net drivers to use instead of the
> keventd_wq? Yeah, I think that'll work. Each driver can also create its
> own workqueue but that may be a bit more wasteful.
>
Isn't the only possibility for a linkwatch deadlock when the
__LINK_STATE_LINKWATCH_PENDING but is set in dev->state?
Off the top of my head...
Would it be interesting to change the calls for flush_scheduled_work()
to a new function net_flush_scheduled_work() with the intent on
eventually creating new a new work queue but temporarily just checking
to make sure there are no linkwatch events pending and if there are
allowing them to run first before calling flush_scheduled_work()?
This probably isn't a perfect solution, but I thought I'd throw it out
there and see what you think....
-andy
^ permalink raw reply
* Question on using Linux as a router
From: Serge Goodenko @ 2006-04-21 14:21 UTC (permalink / raw)
To: netdev
Hi everybody!
I got the following question.
When I use linux as a router (via ip forwarding) what kernel variables (maybe some queues?) represent the closest analogue of usual hardware router input and output buffers? May this be, say, backlog queue or something else?
The things I need to get are the sizes and loads of that buffers during transmission.
I know about variables such as sk->sk_rcvbuf and sk->sk_rmem_alloc but they are not used during ip forwarding as the socket (i.e. sock structure) is not even being created for that purpose. As far as I understood these variables in sock structure are mostly used for tcp-level packet processing and they represent the values written in files like /proc/sys/net/core/wmem_default etc. (please correct me if that's wrong), but nevertheless maybe I also can use these values for "routing" buffers (i.e. on ip level)?
thanks in advance,
Servge
MIPT
Moscow, Russia
^ permalink raw reply
* Re: Congestion Avoidance Monitoring Tools
From: Stephen Hemminger @ 2006-04-21 15:19 UTC (permalink / raw)
To: piet; +Cc: netdev, linux-net
In-Reply-To: <1145597174.12413.17.camel@piet2.bluelane.com>
On Thu, 20 Apr 2006 22:26:14 -0700
Piet Delaney <piet@bluelane.com> wrote:
> I'm upgrading our 2.6.12 kernel to 2.6.13, which includes significant
> congestion avoidance code additions and changes. I was wondering if
> there are any tools folks can recommend for testing the kernel to make
> sure the congestion avoidance code is operating correctly. For
> example the displaying of the congestion window as a function of time
> while undergoing convergence. For causing congestion I could modify
> a kernel to discard packets once in a while on a lab gateway and hit
> it with iperf. HP's netperf looks interesting.
>
> Any suggestions?
>
>
> -piet
>
2.6.13 still had lots of problems, things didn't really get working
right till 2.6.15 or later. Especially with TSO.
I have a tool using kprobe's see http://developer.osdl.org/shemminger/prototypes/tcpprobe.tar.gz
I try to keep it up to date with current kernel and build process, last used it
on 2.6.16.
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: Ingo Oeser @ 2006-04-21 16:52 UTC (permalink / raw)
To: David S. Miller; +Cc: simlo, linux-kernel, mingo, netdev, Ingo Oeser
In-Reply-To: <20060420.120955.28255828.davem@davemloft.net>
Hi David,
nice to see you getting started with it.
I'm not sure about the queue logic there.
1867 /* Caller must have exclusive producer access to the netchannel. */
1868 int netchannel_enqueue(struct netchannel *np, struct netchannel_buftrailer *bp)
1869 {
1870 unsigned long tail;
1871
1872 tail = np->netchan_tail;
1873 if (tail == np->netchan_head)
1874 return -ENOMEM;
This looks wrong, since empty and full are the same condition in your
case.
1891 struct netchannel_buftrailer *__netchannel_dequeue(struct netchannel *np)
1892 {
1893 unsigned long head = np->netchan_head;
1894 struct netchannel_buftrailer *bp = np->netchan_queue[head];
1895
1896 BUG_ON(np->netchan_tail == head);
See?
What about sth. like
struct netchannel {
/* This is only read/written by the writer (producer) */
unsigned long write_ptr;
struct netchannel_buftrailer *netchan_queue[NET_CHANNEL_ENTRIES];
/* This is modified by both */
atomic_t filled_entries; /* cache_line_align this? */
/* This is only read/written by the reader (consumer) */
unsigned long read_ptr;
}
This would prevent this bug from the beginning and let us still use the
full queue size.
If cacheline bouncing because of the shared filled_entries becomes an issue,
you are receiving or sending a lot.
Then you can enqueue and dequeue multiple and commit the counts later.
To be done with a atomic_read, atomic_add and atomic_sub on filled_entries.
Maybe even cheaper with local_t instead of atomic_t later on.
But I guess the cacheline bouncing will be a non-issue, since the whole
point of netchannels was to keep traffic as local to a cpu as possible, right?
Would you like to see a sample patch relative to your tree,
to show you what I mean?
Regards
Ingo Oeser
^ permalink raw reply
* Re: e1000_down and tx_timeout worker race cleaning the transmit buffers
From: Michael Chan @ 2006-04-21 15:28 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Herbert Xu, shawvrana, netdev, auke-jan.h.kok, davem, jgarzik
In-Reply-To: <20060421132758.GA26161@gospo.rdu.redhat.com>
On Fri, 2006-04-21 at 09:27 -0400, Andy Gospodarek wrote:
>
> Isn't the only possibility for a linkwatch deadlock when the
> __LINK_STATE_LINKWATCH_PENDING but is set in dev->state?
This device that you're about to close may be on the linkwatch list, or
other devices may also be on the linkwatch list. As long as
linkwatch_event is in front of your driver's task on the same workqueue,
it will deadlock.
>
> Off the top of my head...
>
> Would it be interesting to change the calls for flush_scheduled_work()
> to a new function net_flush_scheduled_work() with the intent on
> eventually creating new a new work queue but temporarily just checking
> to make sure there are no linkwatch events pending and if there are
> allowing them to run first before calling flush_scheduled_work()?
>
Using the same workqueue and holding the rtnl_lock, I'm not sure how you
can let linkwatch_event run first without deadlocking.
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: Rick Jones @ 2006-04-21 17:12 UTC (permalink / raw)
To: David S. Miller; +Cc: olof, andrew.grover, netdev
In-Reply-To: <20060420.181302.98895633.davem@davemloft.net>
David S. Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Thu, 20 Apr 2006 18:00:37 -0700
>
>
>>Actually, that brings-up a question - presently, and for reasons that
>>are lost to me in the mists of time - netperf will "access" the buffer
>>before it calls recv(). I'm wondering if that should be changed to an
>>access of the buffer after it calls recv()?
>
>
> Yes, that's what it should do, as this is whan a real
> application would do.
Netperf2 TOT now accesses the buffer that was just recv()'d rather than
the one that is about to be recv()'d.
rick jones
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: Ingo Oeser @ 2006-04-21 17:13 UTC (permalink / raw)
To: David S. Miller; +Cc: olof, andrew.grover, netdev, Ingo Oeser
In-Reply-To: <20060420.172742.132879746.davem@davemloft.net>
David S. Miller wrote:
> The first thing an application is going to do is touch that data. So
> I think it's very important to prewarm the caches and the only
> straightforward way I know of to always warm up the correct cpu's
> caches is copy_to_user().
Hmm, what if the application is sth. like a MPEG demultiplexer?
There you don't like to look at everything and excplicitly
ignore received data[1].
Yes, I know this is usually done with hardware demuxers and filters,
but the principle might apply to other applications as well, for which
no hardware solutions exist.
Regards
Ingo Oeser
[1] which you cannot ignore properly with Linux yet.
^ permalink raw reply
* Re: Fw: Bug: PPP dropouts in >=2.6.16
From: Jesse Brandeburg @ 2006-04-21 17:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, Nuri Jawad
In-Reply-To: <20060421010809.6c3cfc34.akpm@osdl.org>
On 4/21/06, Andrew Morton <akpm@osdl.org> wrote:
>
> We do seem to have had a few reports of ppp regressions around this
> timeframe.
me too. I couldn't use 2.6.16 at home on my pppoe connected router
because it was so slow. I didn't have time to debug. I can probably
try patches and provide more data too. Tell me what is needed.
Is there a bugzilla on this?
Jesse
^ 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