* Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections
From: Herbert Xu @ 2005-09-28 2:55 UTC (permalink / raw)
To: David S. Miller
Cc: suzannew, linux-kernel, Robert.Olsson, paulmck, walpole, netdev
In-Reply-To: <20050927.135626.88296134.davem@davemloft.net>
David S. Miller <davem@davemloft.net> wrote:
>
> I agree with the changes to add rcu_dereference() use.
> Those were definitely lacking and needed.
Actually I'm not so sure that they are all needed. I only looked
at the very first one in the patch which is in in_dev_get(). That
one certainly isn't necessary because the old value of ip_ptr
is valid as long as the reference count does not hit zero.
The later is guaranteed by the increment in in_dev_get().
Because the pervasiveness of reference counting in the network stack,
I believe that we should scrutinise the other bits in the patch too
to make sure that they are all needed.
In general, using rcu_dereference/rcu_assign_pointer does not
guarantee correct code. We really need to look at each case
individually.
Cheers,
--
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: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
From: Harald Welte @ 2005-09-28 8:32 UTC (permalink / raw)
To: Henrik Nordstrom; +Cc: netdev, netfilter-devel, Andi Kleen, linux-kernel
In-Reply-To: <Pine.LNX.4.61.0509280219110.25500@filer.marasystems.com>
[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]
On Wed, Sep 28, 2005 at 02:25:16AM +0200, Henrik Nordstrom wrote:
> >That could be special cased and done lockless, with the counting
> >done per CPU.
>
> It's also not very hard for iptables when verifying the table to
> conclude that there really isn't any "real" rules for a certain hook
The detection should be quite straight-forward, yes.
> Allowing you to have as many ip tables modules you like in the kernel,
> but only using the hooks where you have rules.
I totally agree, that from a current perspective, I think the concept of
just loading a module (that has usage count 0) having severe impact on
system performance is just wrong. But then, users are used to the
current behaviour for almost five years now. Every decent script and/or
piece of documentation should by now refer to the fact that loading a
module implicitly registers it at the hooks, and that you only load
those modules that you really need.
In an ideal world, you would load iptables, and userspace would
configure a couple of chains, and then explicitly attach those chains to
the netfilter hooks.
Therefore: Let's do this right next time, but live with that fact for
now.
> Drawback is that you loose the packet counters on the policy.
That's the big problem. People rely on that fact, because they're used
to it. If we introduce some new tool, or something that somehow works
differently, I don't have a change. But silently changing the semantics
with a kernel upgrade is not something that I'm willing to do on
purpose.
Just imagine all those poor sysadmins who know nothing about current
kernel development, and who upgrade their kernel because their
distributor provides a new one - suddenly their accounting (which might
be relevant for their business) doesn't work anymore :(
> Exception: iptable_nat. Needs the hooks for other purposes as well,
> not just the iptable so here the hooks can not be deactivated when
> there is no rules.
yes, even though we could make the ip_nat / iptable_nat split (that is
introduced in 2.6.14) in a way that would make ip_nat.ko register those
hooks that are implicitly needed, and iptable_nat only the user-visible
chain-related hooks.
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
From: Andi Kleen @ 2005-09-28 8:37 UTC (permalink / raw)
To: Harald Welte; +Cc: netdev, netfilter-devel, linux-kernel, Henrik Nordstrom
In-Reply-To: <20050928083240.GP4168@sunbeam.de.gnumonks.org>
On Wednesday 28 September 2005 10:32, Harald Welte wrote:
> I totally agree, that from a current perspective, I think the concept of
> just loading a module (that has usage count 0) having severe impact on
> system performance is just wrong. But then, users are used to the
> current behaviour for almost five years now.
That doesn't mean it cannot be improved - and I think it should.
In a sense it's even getting worse: For example us losing the CONFIG
option to disable local conntrack (Patrick has disabled it some time ago
without even a comment why he did it) has a really bad impact in some cases.
> Therefore: Let's do this right next time, but live with that fact for
> now.
Even with a "quite straight-forward" (quoting you) fix?
> Just imagine all those poor sysadmins who know nothing about current
> kernel development, and who upgrade their kernel because their
> distributor provides a new one - suddenly their accounting (which might
> be relevant for their business) doesn't work anymore :(
Accounting with per CPU counters can be done fully lockless.
-Andi
^ permalink raw reply
* Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
From: Henrik Nordstrom @ 2005-09-28 10:34 UTC (permalink / raw)
To: Harald Welte; +Cc: netdev, netfilter-devel, Andi Kleen, linux-kernel
In-Reply-To: <20050928083240.GP4168@sunbeam.de.gnumonks.org>
On Wed, 28 Sep 2005, Harald Welte wrote:
> Just imagine all those poor sysadmins who know nothing about current
> kernel development, and who upgrade their kernel because their
> distributor provides a new one - suddenly their accounting (which might
> be relevant for their business) doesn't work anymore :(
You seriously expect anyone is using the counters on the policy rule in
otherwise completely empty rulesets? These counters is also available
elsewhere (route and interface statistics) and more intuitively so.
> yes, even though we could make the ip_nat / iptable_nat split (that is
> introduced in 2.6.14) in a way that would make ip_nat.ko register those
> hooks that are implicitly needed, and iptable_nat only the user-visible
> chain-related hooks.
Which adds additional overhead, so this approach is a bit
counter-productive I would say.
Regards
Henrik
^ permalink raw reply
* Re: [PATCH 4/3] rose: fix typo (regeistration)
From: Ralf Baechle DL5RB @ 2005-09-28 11:28 UTC (permalink / raw)
To: David S. Miller; +Cc: adobriyan, linux-hams, netdev
In-Reply-To: <20050927.154537.29000845.davem@davemloft.net>
On Tue, Sep 27, 2005 at 03:45:37PM -0700, David S. Miller wrote:
> I applied these four patches, they look find, thanks.
>
> Ralf, let me know if you have any objections and I'll
> back them out if so :-)
No need to :-)
Ralf
^ permalink raw reply
* Re: ipvs_syncmaster brings cpu to 100%
From: Nishanth Aravamudan @ 2005-09-28 13:26 UTC (permalink / raw)
To: Luca Maranzano, Dave Miller, Wensong Zhang, Julian Anastasov,
netdev
In-Reply-To: <20050928022307.GK18765@verge.net.au>
On 28.09.2005 [11:23:09 +0900], Horms wrote:
> On Mon, Sep 26, 2005 at 07:21:09AM -0700, Nishanth Aravamudan wrote:
> > On 26.09.2005 [15:52:02 +0200], Luca Maranzano wrote:
> > > On 26/09/05, Nishanth Aravamudan <nacc@us.ibm.com> wrote:
> > > > On 26.09.2005 [17:12:32 +0900], Horms wrote:
> > > > > On Mon, Sep 26, 2005 at 05:05:10PM +0900, Horms wrote:
> > > > >
> > > > > [snip]
> > > > >
> > > > > > > > > > Furthermore, if I make an "rgrep" in the source tree of kernel 2.6.12
> > > > > > > > > > the function schedule_timeout() is more used than the ssleep() (517
> > > > > > > > > > occurrencies vs. 43), so why in ip_vs_sync.c there was this change?
> > > > > > > > > >
> > > > > > > > > > The other oddity is that Horms reported on this list that on non Xeon
> > > > > > > > > > CPU the same version of kernel of mine does not present the problem.
> > > > > > > > > >
> > > > > > > > > > I'm getting crazy :-)
> > > > > > > >
> > > > > > > > I've prepared a patch, which reverts the change which was introduced
> > > > > > > > by Nishanth Aravamudan in February.
> > > > > > >
> > > > > > > Was the 100% cpu utilization only occurring on Xeon processors?
> > > > > >
> > > > > > That seems to be the only case where were this problem has been
> > > > > > observed. I don't have such a processor myself, so I haven't actually
> > > > > > been able to produce the problem locally.
> > > > > >
> > > > > > One reason I posted this issue to netdev was to get some more
> > > > > > eyes on the problem as it is puzzling to say the least.
> > > > > >
> > > > > > > Care to try to use msleep_interruptible() instead of ssleep(), as
> > > > > > > opposed to schedule_timeout()?
> > > > > >
> > > > > > I will send a version that does that shortly, Luca, can
> > > > > > you plase check that too?
> > > > >
> > > > > Here is that version of the patch. Nishanth, I take it that I do not
> > > > > need to set TASK_INTERRUPTABLE before calling msleep_interruptible(),
> > > > > please let me know if I am wrong.
> > > >
> > > > Yes, exactly. I'm just trying to narrow it down to see if it's the task
> > > > state that's causing the issue (which, to be honest, doesn't make a lot
> > > > of sense to me -- with ssleep() your load average will go up as the task
> > > > will be UNINTERRUPTIBLE state, but I am not sure why utilisation would
> > > > rise, as you are still sleeping...)
> >
> > [trimmed lvs-users from my reply, as it is a closed list]
> >
> > > Just to add more info, please note the output of "ps":
> > >
> > > debld1:~# ps aux|grep ipvs
> > > root 3748 0.0 0.0 0 0 ? D 12:09 0:00
> > > [ipvs_syncmaster]
> > > root 3757 0.0 0.0 0 0 ? D 12:09 0:00
> > > [ipvs_syncbackup]
> > >
> > > Note the D status, i.e. (from ps(1) man page): Uninterruptible sleep
> > > (usually IO)
> >
> > The msleep_interruptible() change should fix that.
> >
> > But that does not show 100% CPU utilisation at all, it shows 0. Did you
> > mean to say your load increases?
>
> he full discussion is available online at the follwoing URL:
> I can get than information and post it all here if that is
> desirable.
>
> http://archive.linuxvirtualserver.org/html/lvs-users/2005-09/msg00031.html
Yes, the information in that thread is the same as what Luca said. It's
a load average problem, not a CPU utilisation problem (those threads are
sleeping!) If Luca could test the msleep_interruptible() version of the
patch and it works (like I said, performance should not change, but the
load average will drop to by 2), then I will ACK the patch for mainline
acceptance.
Thanks,
Nish
^ permalink raw reply
* vie Click for privacy link. gradient
From: ernesto koko @ 2005-09-28 14:49 UTC (permalink / raw)
To: Kory Struble; +Cc: mendoza, lowe, netdev, daniel
Everything you demand is at this URL.
With our generic, stress is not a big issue no longer.
Certain fast carriage.
Best haggles on net.
Meedical case review for zero pennies.
Absolutely satisfied, would spend again from your zzone. Dorris H --Ohio.
http://uk.geocities.com/timecravingstar/?mpqr
"Jail," said the strange man, coolly putting his handkerchief into his hat,
which was on the floor at his feet. "Or Coavinses."
ferelith evanh flat AH02 ench envseg
Fog everywhere. Fog up the river, where it flows among green aits and
meadows; fog down the river, where it rolls deified among the tiers of
shipping and the waterside pollutions of a great (and dirty) city. Fog on
the Estee marshes, fog on the Kentish heights. Fog creeping into the
cabooses of collier-brigs; fog lying out on the yards and hovering in the
rigging of great ships; fog drooping on the gunwales of barges and small
boats. Fog in the eyes and throats of ancient Greenwich pensioners, wheezing
by the firesides of their wards; fog in the stem and bowl of the afternoon
pipe of the wrathful skipper, down in his close cabin; fog cruelly pinching
the toes and fingers of his shivering little 'prentice boy on deck. Chance
people on the bridges peeping over the pateets into a nether sky of fog,
with fog all round them, as if they were up in a balloon and hanging in the
misty clouds.
Gas looming through the fog in divers places in the streets, much as the
sun may, from the spongey fields, be seen to loom by husbandman and
ploughboy. Most of the shops lighted two hours before their time--as the gas
seems to know, for it has a haggard and unwilling look.
^ permalink raw reply
* Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections
From: Paul E. McKenney @ 2005-09-28 14:51 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, suzannew, linux-kernel, Robert.Olsson, walpole,
netdev
In-Reply-To: <E1EKS6j-0006s4-00@gondolin.me.apana.org.au>
On Wed, Sep 28, 2005 at 12:55:45PM +1000, Herbert Xu wrote:
> David S. Miller <davem@davemloft.net> wrote:
> >
> > I agree with the changes to add rcu_dereference() use.
> > Those were definitely lacking and needed.
>
> Actually I'm not so sure that they are all needed. I only looked
> at the very first one in the patch which is in in_dev_get(). That
> one certainly isn't necessary because the old value of ip_ptr
> is valid as long as the reference count does not hit zero.
>
> The later is guaranteed by the increment in in_dev_get().
>
> Because the pervasiveness of reference counting in the network stack,
> I believe that we should scrutinise the other bits in the patch too
> to make sure that they are all needed.
>
> In general, using rcu_dereference/rcu_assign_pointer does not
> guarantee correct code. We really need to look at each case
> individually.
Yep, these two APIs are only part of the solution.
The reference-count approach is only guaranteed to work if the kernel
thread that did the reference-count increment is later referencing that
same data element. Otherwise, one has the following possible situation
on DEC Alpha:
o CPU 0 initializes and inserts a new element into the data
structure, using rcu_assign_pointer() to provide any needed
memory barriers. (Or, if RCU is not being used, under the
appropriate update-side lock.)
o CPU 1 acquires a reference to this new element, presumably
using either a lock or rcu_read_lock() and rcu_dereference()
in order to do so safely. CPU 1 then increments the reference
count.
o CPU 2 picks up a pointer to this new element, but in a way
that relies on the reference count having been incremented,
without using locking, rcu_read_lock(), rcu_dereference(),
and so on.
This CPU can then see the pre-initialized contents of the
newly inserted data structure (again, but only on DEC Alpha).
Again, if the same kernel thread that incremented the reference count
is later accessing it, no problem, even on Alpha.
Thanx, Paul
^ permalink raw reply
* Re: rwlock recursion on CPU#0, netfilter related?
From: Pekka Pietikainen @ 2005-09-28 14:58 UTC (permalink / raw)
To: Harald Welte; +Cc: netdev
In-Reply-To: <20050925201945.GA21176@ee.oulu.fi>
On Sun, Sep 25, 2005 at 11:19:45PM +0300, Pekka Pietikainen wrote:
> Enabled, so this could be it. But 2.6.14-rc2-git4 did crash too (although
> it did take a bit longer for that to happen), and the changelog does state:
Ok, it looks like that patch was the thing after all. I now tried the latest
fedora-devel kernel (1.1582, based on 2.6.14-rc2-git6) and the box has been
running for a few hours happily. Could be the fedora kernel that claimed to
be git4 actually wasn't, or the git4 changelog was really a post-git4
changelog :). But anyway, bug is gone.
> > But only in 1 out of ten cases on average (when starting ping, ctrl+c,
> > pin, ctrl+c, ...). I've always assumed it's some 64bit problem in
> > "ping" itself.
> Happens for all packets on the "broken" kernels, and works a-ok (few ms
> latencies to the same box) on the 2.6.13-era ones that don't crash.
> Could be a different bug, sure.
This one is still around, so it's a different bug. Looks like it's a 64-bit
issue, a 32-bit ping gives realistic ping times. tcpdump timestamps are also
affected, they're completely off too. So looks like someone broke packet
timestamps on 64-bit some time after 2.6.13.
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Ion Badulescu @ 2005-09-28 16:31 UTC (permalink / raw)
To: Alexey Kuznetsov; +Cc: David S. Miller, linux-kernel, linux-net, netdev
In-Reply-To: <20050902183656.GA16537@yakov.inr.ac.ru>
Hi Alexey,
On Fri, 2 Sep 2005, Alexey Kuznetsov wrote:
> Anyway, ignoring this puzzle, the following patch for 2.4 should help.
>
>
> --- net/ipv4/tcp_input.c.orig 2003-02-20 20:38:39.000000000 +0300
> +++ net/ipv4/tcp_input.c 2005-09-02 22:28:00.845952888 +0400
> @@ -343,8 +343,6 @@
> app_win -= tp->ack.rcv_mss;
> app_win = max(app_win, 2U*tp->advmss);
>
> - if (!ofo_win)
> - tp->window_clamp = min(tp->window_clamp, app_win);
> tp->rcv_ssthresh = min(tp->window_clamp, 2U*tp->advmss);
> }
> }
I'm very happy to report that the above patch, applied to 2.6.12.6, seems
to have cured the TCP window problem we were experiencing. I've been
testing it extensively over the last 4 weeks, and I have yet to see any
repeats of the previous behavior.
The TCP window now usually settles to around 4k (unscaled, 16k scaled),
which is smallish but good enough for our purposes.
Thanks,
-Ion
^ permalink raw reply
* Re: TCP Network performance degade from 2.4.18 to 2.6.10
From: Stephen Hemminger @ 2005-09-28 16:35 UTC (permalink / raw)
To: Eshwar; +Cc: linux-kernel, netdev
In-Reply-To: <LEXUSAX3cf3ednHM3SO00000be8@lexus.moschip.com>
On Wed, 28 Sep 2005 10:42:22 +0530
"Eshwar" <eshwar@moschip.com> wrote:
> HI all,
>
> I observed there is huge network performance drop from linux 2.4 to 2.6 with
> the same setup (No hardware changes..). The results are taken in PIV
> processor with D-Link network card... with iperf ... Can some body help me
> why such a huge difference... in TCP stream...
>
> In linux 2.4 (Redhat 9)
>
> DLink
> TCP UDP
> Tx 94.3Mbps Tx 95 Mbps
> Rx 94.2 Mbps Rx 95 Mbps
>
> In linux 2.6.10 (Fedora Core 4)
> DLink
> TCP UDP
> Tx 64.3 Mbps Tx 87 Mbps
> Rx 88.1 Mbps Rx 95 Mbps
>
>
> Thanks & Regards
> Eshwar
Please send network performance discussion to netdev@vger.kernel.org
A lot more information is needed, like:
* which hardware is on both ends of the test (lscpci)
* any TCP configuration issues
* any errors reported.
* netfilter and firewalling.
^ permalink raw reply
* [PATCH] net/bluetooth/lib.c: remove unneeded #defines
From: Alexey Dobriyan @ 2005-09-28 20:28 UTC (permalink / raw)
To: Marcel Holtmann, Maxim Krasnyansky; +Cc: bluez-devel, netdev
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
net/bluetooth/lib.c | 3 ---
1 file changed, 3 deletions(-)
--- a/net/bluetooth/lib.c
+++ b/net/bluetooth/lib.c
@@ -24,12 +24,9 @@
/* Bluetooth kernel library. */
-#include <linux/config.h>
#include <linux/module.h>
#include <linux/kernel.h>
-#include <linux/stddef.h>
-#include <linux/string.h>
#include <asm/errno.h>
#include <net/bluetooth/bluetooth.h>
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
^ permalink raw reply
* [patch 2.6.14-rc2 1/2] s2io: change strncpy length arg to use size of target
From: John W. Linville @ 2005-09-28 21:50 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: jgarzik, leonid.grossman
In-Reply-To: <09282005175051.10698@bilbo.tuxdriver.com>
Use the size of the target array for the length argument to strncpy
instead of the size of the source or a magic number.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/s2io.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -3778,11 +3778,10 @@ static void s2io_ethtool_gdrvinfo(struct
{
nic_t *sp = dev->priv;
- strncpy(info->driver, s2io_driver_name, sizeof(s2io_driver_name));
- strncpy(info->version, s2io_driver_version,
- sizeof(s2io_driver_version));
- strncpy(info->fw_version, "", 32);
- strncpy(info->bus_info, pci_name(sp->pdev), 32);
+ strncpy(info->driver, s2io_driver_name, sizeof(info->driver));
+ strncpy(info->version, s2io_driver_version, sizeof(info->version));
+ strncpy(info->fw_version, "", sizeof(info->fw_version));
+ strncpy(info->bus_info, pci_name(sp->pdev), sizeof(info->bus_info));
info->regdump_len = XENA_REG_SPACE;
info->eedump_len = XENA_EEPROM_SPACE;
info->testinfo_len = S2IO_TEST_LEN;
^ permalink raw reply
* [patch 2.6.14-rc2 0/2] minor cleanups for s2io
From: John W. Linville @ 2005-09-28 21:50 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: jgarzik, leonid.grossman
A couple of minor cleanups for the s2io driver:
-- Use the target length as the third argument to strncpy
in s2io_ethtool_gdrvinfo()
-- Add a MODULE_VERSION entry
Patches to follow...
^ permalink raw reply
* [patch 2.6.14-rc2 2/2] s2io: add MODULE_VERSION to s2io driver
From: John W. Linville @ 2005-09-28 21:50 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: jgarzik, leonid.grossman
In-Reply-To: <09282005175051.10754@bilbo.tuxdriver.com>
Add a MODULE_VERSION entry for the s2io driver.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/s2io.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -65,9 +65,11 @@
#include "s2io.h"
#include "s2io-regs.h"
+#define DRV_VERSION "2.0.8.1"
+
/* S2io Driver name & version. */
static char s2io_driver_name[] = "Neterion";
-static char s2io_driver_version[] = "Version 2.0.8.1";
+static char s2io_driver_version[] = DRV_VERSION;
static inline int RXD_IS_UP2DT(RxD_t *rxdp)
{
@@ -5227,6 +5229,8 @@ static void s2io_init_pci(nic_t * sp)
MODULE_AUTHOR("Raghavendra Koushik <raghavendra.koushik@neterion.com>");
MODULE_LICENSE("GPL");
+MODULE_VERSION(DRV_VERSION);
+
module_param(tx_fifo_num, int, 0);
module_param(rx_ring_num, int, 0);
module_param_array(tx_fifo_len, uint, NULL, 0);
@@ -5570,7 +5574,7 @@ s2io_init_nic(struct pci_dev *pdev, cons
if (sp->device_type & XFRAME_II_DEVICE) {
DBG_PRINT(ERR_DBG, "%s: Neterion Xframe II 10GbE adapter ",
dev->name);
- DBG_PRINT(ERR_DBG, "(rev %d), %s",
+ DBG_PRINT(ERR_DBG, "(rev %d), Version %s",
get_xena_rev_id(sp->pdev),
s2io_driver_version);
#ifdef CONFIG_2BUFF_MODE
@@ -5594,7 +5598,7 @@ s2io_init_nic(struct pci_dev *pdev, cons
} else {
DBG_PRINT(ERR_DBG, "%s: Neterion Xframe I 10GbE adapter ",
dev->name);
- DBG_PRINT(ERR_DBG, "(rev %d), %s",
+ DBG_PRINT(ERR_DBG, "(rev %d), Version %s",
get_xena_rev_id(sp->pdev),
s2io_driver_version);
#ifdef CONFIG_2BUFF_MODE
^ permalink raw reply
* [patch 2.6.14-rc2] bonding: replicate IGMP traffic in activebackup mode
From: John W. Linville @ 2005-09-28 21:50 UTC (permalink / raw)
To: linux-kernel, netdev, bonding-devel; +Cc: ctindel, fubar, jgarzik
Replicate IGMP frames across all slaves in activebackup mode. This
ensures fail-over is rapid for multicast traffic as well. Otherwise,
multicast traffic will be lost until the next IGMP membership report
poll timeout.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
This is conceptually similar to the treatment of IGMP traffic in
bond_alb_xmit. In that case, IGMP traffic transmitted on any slave
is re-routed to the active slave in order to ensure that multicast
traffic continues to be directed to the active receiver.
drivers/net/bonding/bond_main.c | 53 ++++++++++++++++++++++++++++++++++++++--
1 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4391,6 +4391,39 @@ out:
return 0;
}
+static void bond_activebackup_xmit_copy(struct sk_buff *skb,
+ struct bonding *bond,
+ struct slave *slave)
+{
+ struct sk_buff *skb2 = skb_copy(skb, GFP_ATOMIC);
+ struct ethhdr *eth_data;
+ u8 *hwaddr;
+ int res;
+
+ if (!skb2) {
+ printk(KERN_ERR DRV_NAME ": Error: "
+ "bond_activebackup_xmit_copy(): skb_copy() failed\n");
+ return;
+ }
+
+ skb2->mac.raw = (unsigned char *)skb2->data;
+ eth_data = eth_hdr(skb2);
+
+ /* Pick an appropriate source MAC address */
+ hwaddr = slave->perm_hwaddr;
+ if (!memcmp(eth_data->h_source, hwaddr, ETH_ALEN))
+ hwaddr = bond->curr_active_slave->perm_hwaddr;
+
+ /* Set source MAC address appropriately */
+ memcpy(eth_data->h_source, hwaddr, ETH_ALEN);
+
+ res = bond_dev_queue_xmit(bond, skb2, slave->dev);
+ if (res)
+ dev_kfree_skb(skb2);
+
+ return;
+}
+
/*
* in active-backup mode, we know that bond->curr_active_slave is always valid if
* the bond has a usable interface.
@@ -4407,10 +4440,26 @@ static int bond_xmit_activebackup(struct
goto out;
}
- if (bond->curr_active_slave) { /* one usable interface */
- res = bond_dev_queue_xmit(bond, skb, bond->curr_active_slave->dev);
+ if (!bond->curr_active_slave)
+ goto out;
+
+ /* Xmit IGMP frames on all slaves to ensure rapid fail-over
+ for multicast traffic on snooping switches */
+ if (skb->protocol == __constant_htons(ETH_P_IP) &&
+ skb->nh.iph->protocol == IPPROTO_IGMP) {
+ struct slave *slave, *active_slave;
+ int i;
+
+ active_slave = bond->curr_active_slave;
+ bond_for_each_slave_from_to(bond, slave, i, active_slave->next,
+ active_slave->prev)
+ if (IS_UP(slave->dev) &&
+ (slave->link == BOND_LINK_UP))
+ bond_activebackup_xmit_copy(skb, bond, slave);
}
+ res = bond_dev_queue_xmit(bond, skb, bond->curr_active_slave->dev);
+
out:
if (res) {
/* no suitable interface, frame not sent */
^ permalink raw reply
* Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections
From: Herbert Xu @ 2005-09-28 22:11 UTC (permalink / raw)
To: Paul E. McKenney
Cc: David S. Miller, suzannew, linux-kernel, Robert.Olsson, walpole,
netdev
In-Reply-To: <20050928145110.GA4925@us.ibm.com>
On Wed, Sep 28, 2005 at 07:51:10AM -0700, Paul E. McKenney wrote:
>
> The reference-count approach is only guaranteed to work if the kernel
> thread that did the reference-count increment is later referencing that
> same data element. Otherwise, one has the following possible situation
> on DEC Alpha:
You're quite right. Without the rcu_dereference users of in_dev_get()
may see pre-initialisation contents of in_dev.
So these barriers are definitely needed.
Thanks,
--
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: ipvs_syncmaster brings cpu to 100%
From: Julian Anastasov @ 2005-09-29 7:00 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: Luca Maranzano, Dave Miller, Wensong Zhang, netdev
In-Reply-To: <20050928132639.GA5791@us.ibm.com>
Hello,
On Wed, 28 Sep 2005, Nishanth Aravamudan wrote:
> Yes, the information in that thread is the same as what Luca said. It's
> a load average problem, not a CPU utilisation problem (those threads are
> sleeping!) If Luca could test the msleep_interruptible() version of the
> patch and it works (like I said, performance should not change, but the
> load average will drop to by 2), then I will ACK the patch for mainline
> acceptance.
Agreed. It seems your initial conversion was based on wrong
assumptions, quoting you:
> Description: Use ssleep() instead of schedule_timeout() to guarantee the task
> delays as expected. The first two replacements use TASK_INTERRUPTIBLE but do
> not
> check for signals, so ssleep() should be appropriate.
As all signals are blocked from daemonize and even explicitly
later it was not necessary to convert to non-interruptible variant.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* chuckwalla Smart medicinal varieties match your needs. acclaim
From: jeramy patino @ 2005-09-29 11:44 UTC (permalink / raw)
To: Olin Theodoratos; +Cc: netdev, daniel, linux-xfs-outgoing, reese, hunter, ljp
It's very economical compares to your local pharmaceutical.
Clear your inflammation with our tabblet.
Trusted global carriage network for all consignments.
Our shoppers agree that ours is min prices.
For save consumption, a GP will verifies your meddical record.
I just receiving my capsulees, they are thump up, uh-huh!! Liz B --CA.
http://uk.geocities.com/timecosycozystar/?ab
"It's twenty-four pound, sixteen, and sevenpence ha'penny," observed the
stranger. "That's wot it is."
fehle dibon emplist AH02 fbmsf beltrovata
At noon Philip Horton made his way through the crowd with a tray and a tin
coffee-pot from the camp kitchen. When he reached the carriage he found Mrs.
Alexander just as he had left her in the early morning, leaning forward a
little, with her hand on the lowered window, looking at the river. Hour
after hour she had been watching the water, the lonely, useless stone
towers, and the convulsed mass of iron wreckage over which the angry river
continually spat up its yellow foam.
"Those poor women out there, do they blame him very much?" she asked, as
she handed the coffee-cup back to Horton.
^ permalink raw reply
* Re: rwlock recursion on CPU#0, netfilter related?
From: Harald Welte @ 2005-09-29 12:05 UTC (permalink / raw)
To: Pekka Pietikainen; +Cc: netdev
In-Reply-To: <20050928145815.GA421@ee.oulu.fi>
[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]
On Wed, Sep 28, 2005 at 05:58:15PM +0300, Pekka Pietikainen wrote:
> On Sun, Sep 25, 2005 at 11:19:45PM +0300, Pekka Pietikainen wrote:
> > Enabled, so this could be it. But 2.6.14-rc2-git4 did crash too (although
> > it did take a bit longer for that to happen), and the changelog does state:
> Ok, it looks like that patch was the thing after all. I now tried the latest
> fedora-devel kernel (1.1582, based on 2.6.14-rc2-git6) and the box has been
> running for a few hours happily. Could be the fedora kernel that claimed to
> be git4 actually wasn't, or the git4 changelog was really a post-git4
> changelog :). But anyway, bug is gone.
great news.
> This one is still around, so it's a different bug. Looks like it's a 64-bit
> issue, a 32-bit ping gives realistic ping times. tcpdump timestamps are also
> affected, they're completely off too. So looks like someone broke packet
> timestamps on 64-bit some time after 2.6.13.
luckily I'm not the core network maintainer ;)
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Alexey Kuznetsov @ 2005-09-29 15:17 UTC (permalink / raw)
To: Ion Badulescu; +Cc: David S. Miller, linux-kernel, linux-net, netdev, gautran
In-Reply-To: <Pine.LNX.4.61.0509281223560.30951@ionlinux.tower-research.com>
Hello!
> >Anyway, ignoring this puzzle, the following patch for 2.4 should help.
> >
> >
> >--- net/ipv4/tcp_input.c.orig 2003-02-20 20:38:39.000000000 +0300
> >+++ net/ipv4/tcp_input.c 2005-09-02 22:28:00.845952888 +0400
> >@@ -343,8 +343,6 @@
> > app_win -= tp->ack.rcv_mss;
> > app_win = max(app_win, 2U*tp->advmss);
> >
> >- if (!ofo_win)
> >- tp->window_clamp = min(tp->window_clamp, app_win);
> > tp->rcv_ssthresh = min(tp->window_clamp, 2U*tp->advmss);
> > }
> >}
>
> I'm very happy to report that the above patch, applied to 2.6.12.6, seems
> to have cured the TCP window problem we were experiencing.
Good. I think the patch is to be applied to all mainstream kernels.
The only obstacle is the second report by Guillaume Autran <gautran@mrv.com>,
which has some allied characteristics, but after analysis it is something
impossible, read, cryptic and severe bug. :-( I did not get a responce
to the last query, so the investigation stalled.
Alexey
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Guillaume Autran @ 2005-09-29 15:34 UTC (permalink / raw)
To: Alexey Kuznetsov
Cc: Ion Badulescu, David S. Miller, linux-kernel, linux-net, netdev
In-Reply-To: <20050929151729.GA2158@ms2.inr.ac.ru>
Hi!
Sorry Alexey for keeping it quiet but I got pulled away to some other duties for
the past 3 weeks.
Anyway, the similar problem I was reporting has not been seen since that last
incident a month ago. We did change, on our application side, some of the
parameters (aka SO_RCVBUF) that did not need to be set in the first place (bug
on our side).
This plus your patch seem to have resolve the issues we were having. So, it's
all good !
Thanks again..
Guillaume.
Alexey Kuznetsov wrote:
> Hello!
>
>
>>>Anyway, ignoring this puzzle, the following patch for 2.4 should help.
>>>
>>>
>>>--- net/ipv4/tcp_input.c.orig 2003-02-20 20:38:39.000000000 +0300
>>>+++ net/ipv4/tcp_input.c 2005-09-02 22:28:00.845952888 +0400
>>>@@ -343,8 +343,6 @@
>>> app_win -= tp->ack.rcv_mss;
>>> app_win = max(app_win, 2U*tp->advmss);
>>>
>>>- if (!ofo_win)
>>>- tp->window_clamp = min(tp->window_clamp, app_win);
>>> tp->rcv_ssthresh = min(tp->window_clamp, 2U*tp->advmss);
>>> }
>>>}
>>
>>I'm very happy to report that the above patch, applied to 2.6.12.6, seems
>>to have cured the TCP window problem we were experiencing.
>
>
> Good. I think the patch is to be applied to all mainstream kernels.
>
> The only obstacle is the second report by Guillaume Autran <gautran@mrv.com>,
> which has some allied characteristics, but after analysis it is something
> impossible, read, cryptic and severe bug. :-( I did not get a responce
> to the last query, so the investigation stalled.
>
> Alexey
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
=======================================
^ permalink raw reply
* Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections
From: Suzanne Wood @ 2005-09-29 16:02 UTC (permalink / raw)
To: paulmck
Cc: Robert.Olsson, davem, herbert, linux-kernel, netdev, suzannew,
walpole
The original motivation for this patch was in __in_dev_get
usage. I'll try to test a build, but should submittals be
incremental? first addressing in_dev_get, then
__in_dev_get? What seems resolved so far follows.
The exchange below suggests that it is equally important
to have the rcu_dereference() in __in_dev_get(), so the
idea of the only difference between in_dev_get and
__in_dev_get being the refcnt may be accepted.
Correct usage may be a question with the mismatched
definitions (in terms of refcnt) of __in_dev_get()
and __in_dev_put() that superficially appear
paired and this may merit a comment. If interested,
examples are mentioned in
www.uwsg.iu.edu/hypermail/linux/kernel/0509.1/0184.html
and
www.ussg.iu.edu/hypermail/linux/kernel/0509.3/0757.html
But when the refcnt is employed for the DEC Alpha,
rcu-protection or other locking must be in place for
multiple CPUs, which apparently affirms the value
of the marking of an rcu read-side critical section
done by the calling function which has the vision of the
extent of use of the protected dereference.
Is this all reasonable to you?
Thank you very much.
----- Original Message -----
From: Paul E. McKenney
Sent: Wednesday, September 28, 2005 7:51 AM
> On Wed, Sep 28, 2005 at 12:55:45PM +1000, Herbert Xu wrote:
>> David S. Miller wrote:
>> >
>> > I agree with the changes to add rcu_dereference() use.
>> > Those were definitely lacking and needed.
>>
>> Actually I'm not so sure that they are all needed. I only looked
>> at the > guarantee correct code. We really need to look at each case
>> individually.
>
> Yep, these two APIs are only part of the solution.
>
> The reference-count approach is only guaranteed to work if the kernel
> thread that did the reference-count increment is later referencing that
> same data element. Otherwise, one has the following possible situation
> on DEC Alpha:
>
> o CPU 0 initializes and inserts a new element into the data
> structure, using rcu_assign_pointer() to provide any needed
> memory barriers. (Or, if RCU is not being used, under the
> appropriate update-side lock.)
>
> o CPU 1 acquires a reference to this new element, presumably
> using either a lock or rcu_read_lock() and rcu_dereference()
> in order to do so safely. CPU 1 then increments the reference
> count.
>
> o CPU 2 picks up a pointer to this new element, but in a way
> that relies on the reference count having been incremented,
> without using locking, rcu_read_lock(), rcu_dereference(),
> and so on.
>
> This CPU can then see the pre-initialized contents of the
> newly inserted data structure (again, but only on DEC Alpha).
>
> Again, if the same kernel thread that incremented the reference count
> is later accessing it, no problem, even on Alpha.
>
> Thanx, Paul
>
^ permalink raw reply
* Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: John Heffner @ 2005-09-29 16:04 UTC (permalink / raw)
To: Alexey Kuznetsov
Cc: Ion Badulescu, David S. Miller, linux-kernel, linux-net, netdev,
gautran
In-Reply-To: <20050929151729.GA2158@ms2.inr.ac.ru>
[-- Attachment #1: Type: text/plain, Size: 2317 bytes --]
On Thursday 29 September 2005 11:17 am, Alexey Kuznetsov wrote:
> Hello!
>
> > >Anyway, ignoring this puzzle, the following patch for 2.4 should help.
> > >
> > >
> > >--- net/ipv4/tcp_input.c.orig 2003-02-20 20:38:39.000000000 +0300
> > >+++ net/ipv4/tcp_input.c 2005-09-02 22:28:00.845952888 +0400
> > >@@ -343,8 +343,6 @@
> > > app_win -= tp->ack.rcv_mss;
> > > app_win = max(app_win, 2U*tp->advmss);
> > >
> > >- if (!ofo_win)
> > >- tp->window_clamp = min(tp->window_clamp, app_win);
> > > tp->rcv_ssthresh = min(tp->window_clamp, 2U*tp->advmss);
> > > }
> > >}
> >
> > I'm very happy to report that the above patch, applied to 2.6.12.6, seems
> > to have cured the TCP window problem we were experiencing.
>
> Good. I think the patch is to be applied to all mainstream kernels.
Has anyone looked at the patch I sent out on Sept 9? It goes a few steps
further, addressing some additional problems. Original message below.
Thanks,
-John
-----
This is a patch for discussion addressing some receive buffer growing issues.
This is partially related to the thread "Possible BUG in IPv4 TCP window
handling..." last week.
Specifically it addresses the problem of an interaction between rcvbuf
moderation (receiver autotuning) and rcv_ssthresh. The problem occurs when
sending small packets to a receiver with a larger MTU. (A very common case I
have is a host with a 1500 byte MTU sending to a host with a 9k MTU.) In
such a case, the rcv_ssthresh code is targeting a window size corresponding
to filling up the current rcvbuf, not taking into account that the new rcvbuf
moderation may increase the rcvbuf size.
One hunk makes rcv_ssthresh use tcp_rmem[2] as the size target rather than
rcvbuf. The other changes the behavior when it overflows its memory bounds
with in-order data so that it tries to grow rcvbuf (the same as with
out-of-order data).
These changes should help my problem of mixed MTUs, and should also help the
case from last week's thread I think. (In both cases though you still need
tcp_rmem[2] to be set much larger than the TCP window.) One question is if
this is too aggressive at trying to increase rcvbuf if it's under memory
stress.
-John
Signed-off-by: John Heffner <jheffner@psc.edu>
[-- Attachment #2: rcv_ssthresh.diff --]
[-- Type: text/x-diff, Size: 2005 bytes --]
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -233,7 +233,7 @@ static int __tcp_grow_window(const struc
{
/* Optimize this! */
int truesize = tcp_win_from_space(skb->truesize)/2;
- int window = tcp_full_space(sk)/2;
+ int window = tcp_win_from_space(sysctl_tcp_rmem[2])/2;
while (tp->rcv_ssthresh <= window) {
if (truesize <= skb->len)
@@ -326,39 +326,18 @@ static void tcp_init_buffer_space(struct
static void tcp_clamp_window(struct sock *sk, struct tcp_sock *tp)
{
struct inet_connection_sock *icsk = inet_csk(sk);
- struct sk_buff *skb;
- unsigned int app_win = tp->rcv_nxt - tp->copied_seq;
- int ofo_win = 0;
icsk->icsk_ack.quick = 0;
- skb_queue_walk(&tp->out_of_order_queue, skb) {
- ofo_win += skb->len;
+ if (sk->sk_rcvbuf < sysctl_tcp_rmem[2] &&
+ !(sk->sk_userlocks & SOCK_RCVBUF_LOCK) &&
+ !tcp_memory_pressure &&
+ atomic_read(&tcp_memory_allocated) < sysctl_tcp_mem[0]) {
+ sk->sk_rcvbuf = min(atomic_read(&sk->sk_rmem_alloc),
+ sysctl_tcp_rmem[2]);
}
-
- /* If overcommit is due to out of order segments,
- * do not clamp window. Try to expand rcvbuf instead.
- */
- if (ofo_win) {
- if (sk->sk_rcvbuf < sysctl_tcp_rmem[2] &&
- !(sk->sk_userlocks & SOCK_RCVBUF_LOCK) &&
- !tcp_memory_pressure &&
- atomic_read(&tcp_memory_allocated) < sysctl_tcp_mem[0])
- sk->sk_rcvbuf = min(atomic_read(&sk->sk_rmem_alloc),
- sysctl_tcp_rmem[2]);
- }
- if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) {
- app_win += ofo_win;
- if (atomic_read(&sk->sk_rmem_alloc) >= 2 * sk->sk_rcvbuf)
- app_win >>= 1;
- if (app_win > icsk->icsk_ack.rcv_mss)
- app_win -= icsk->icsk_ack.rcv_mss;
- app_win = max(app_win, 2U*tp->advmss);
-
- if (!ofo_win)
- tp->window_clamp = min(tp->window_clamp, app_win);
+ if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf)
tp->rcv_ssthresh = min(tp->window_clamp, 2U*tp->advmss);
- }
}
/* Receiver "autotuning" code.
^ permalink raw reply
* Re: [PATCH] net/bluetooth/lib.c: remove unneeded #defines
From: Marcel Holtmann @ 2005-09-29 16:41 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: Maxim Krasnyansky, bluez-devel, netdev
In-Reply-To: <20050928202856.GA27645@mipter.zuzino.mipt.ru>
Hi Alexey,
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> ---
>
> net/bluetooth/lib.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> --- a/net/bluetooth/lib.c
> +++ b/net/bluetooth/lib.c
> @@ -24,12 +24,9 @@
>
> /* Bluetooth kernel library. */
>
> -#include <linux/config.h>
> #include <linux/module.h>
>
> #include <linux/kernel.h>
> -#include <linux/stddef.h>
> -#include <linux/string.h>
> #include <asm/errno.h>
>
> #include <net/bluetooth/bluetooth.h>
thanks for the patch. Do you have more of them? If yes, then I like to
cleanup this in one row and not step by step.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
^ 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