* Out of Office AutoReply: [FMG-SPAM] - AL J RAJITDQTQH - Bayesian Filter detected spam
From: Liesbet Nyssen @ 2005-09-26 14:30 UTC (permalink / raw)
To: netdev
I'm out of office until October 25th and will have only limited access to my email. Please, contact me again later. Liesbet Nyssen
^ permalink raw reply
* RE: [FMG-SPAM] - AL J RAJITDQTQH - Bayesian Filter detected spam
From: Liesbet Nyssen @ 2005-09-26 14:30 UTC (permalink / raw)
To: netdev
I'm out of office until October 25th and will have only limited access to my email. Please contact me again later. Liesbet Nyssen
^ permalink raw reply
* Re: ipvs_syncmaster brings cpu to 100%
From: Nishanth Aravamudan @ 2005-09-26 14:21 UTC (permalink / raw)
To: Luca Maranzano; +Cc: Dave Miller, Wensong Zhang, Julian Anastasov, netdev
In-Reply-To: <68559cef05092606521cc13f9a@mail.gmail.com>
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?
I'm still unclear what the problem is. Horms initial Cc trimmed some
important information. It would be very useful to "start over" -- at
least from the perspective of what the problem actually is.
> I hope to have a Xeon machine to make some more tests in the next
> days, in the mean time I'll try to reproduce my setup on a couple of
> VMWare Workstation machines.
Please don't top-most. It makes it really hard to write sane replies...
Thanks,
Nish
^ permalink raw reply
* Re: ipvs_syncmaster brings cpu to 100%
From: Luca Maranzano @ 2005-09-26 13:52 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: LinuxVirtualServer.org users mailing list., Dave Miller,
Wensong Zhang, Julian Anastasov, netdev
In-Reply-To: <20050926131104.GA7532@us.ibm.com>
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)
I hope to have a Xeon machine to make some more tests in the next
days, in the mean time I'll try to reproduce my setup on a couple of
VMWare Workstation machines.
More later.
Thank you all.
Luca
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...)
>
> Thanks,
> Nish
>
^ permalink raw reply
* Re: [ANNOUNCE] Release of nf-HiPAC 0.9.0
From: jamal @ 2005-09-26 13:31 UTC (permalink / raw)
To: Michael Bellion; +Cc: linux-kernel, linux-net, netdev
In-Reply-To: <200509261516.16565.mbellion@hipac.org>
On Mon, 2005-26-09 at 15:16 +0200, Michael Bellion wrote:
> Hi,
>
> > Can you post some numbers relative to iptables?
>
> We have some performance tests available at:
> http://www.hipac.org/performance_tests/overview.html
>
> We also have a list of the independent performance tests we know of:
> http://www.hipac.org/performance_tests/independent.html
>
Can you please post something against new kernels you are patching
against _today_? I recall these same graphs from a few years back but
even iptables has improved since.
Any issues you may find can only help you improve.
BTW, your tests were unfair to iptables; you should have had optimized
the rules with the assumption that someone needing that many rules would
probably have needed to do some optimization even with iptables.
Yes, it would only have taken one year to load 256K rules, but it would
have loaded eventually.
> > Some tests with the following parameters would be helpful:
> > - Variable incoming packet rate (in packets per second)
> > - Variable packet sizes
> > - Variable number of users/filters
> > - Effect of adding/removing/modifying policies while under different
> > incoming traffic rates.
>
> Most of this parameters are used in the performance tests above.
>
> The effect of adding/removing/modifying policies while under different
> incoming traffic rates has not been tested in the above tests.
>
> nf-HiPAC is based on a completely dynamic approach.
Very good. Please do more up to date testing and try to include tc
filter as well.
cheers,
jamal
^ permalink raw reply
* Re: [ANNOUNCE] Release of nf-HiPAC 0.9.0
From: Michael Bellion @ 2005-09-26 13:16 UTC (permalink / raw)
To: hadi; +Cc: linux-kernel, linux-net, netdev
In-Reply-To: <1127733492.6215.274.camel@localhost.localdomain>
Hi,
> Can you post some numbers relative to iptables?
We have some performance tests available at:
http://www.hipac.org/performance_tests/overview.html
We also have a list of the independent performance tests we know of:
http://www.hipac.org/performance_tests/independent.html
> Some tests with the following parameters would be helpful:
> - Variable incoming packet rate (in packets per second)
> - Variable packet sizes
> - Variable number of users/filters
> - Effect of adding/removing/modifying policies while under different
> incoming traffic rates.
Most of this parameters are used in the performance tests above.
The effect of adding/removing/modifying policies while under different
incoming traffic rates has not been tested in the above tests.
nf-HiPAC is based on a completely dynamic approach.
This means that the algorithm used in HiPAC makes sure that the lookup data
structure is not rebuild from scratch again as soon as you make a update of
the data structure.
Instead during an update of the policies only the required changes of the
lookup data structure are made. This guaranties that the packet processing is
only affected to the least possible amount during updates.
It would certainly be nice to see some benchmark results for this case.
nf-HiPAC is expected to handle this very well, because it was designed with
this case in mind.
Regards
+---------------------------+
| Michael Bellion |
| <mbellion@hipac.org> |
+---------------------------+
^ permalink raw reply
* Re: ipvs_syncmaster brings cpu to 100%
From: Nishanth Aravamudan @ 2005-09-26 13:11 UTC (permalink / raw)
To: Roger Tsang, Luca Maranzano,
LinuxVirtualServer.org users mailing list., Dave Miller,
Wensong Zhang, Julian Anastasov, netdev
In-Reply-To: <20050926081229.GA23755@verge.net.au>
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...)
Thanks,
Nish
^ permalink raw reply
* Re: [ANNOUNCE] Release of nf-HiPAC 0.9.0
From: jamal @ 2005-09-26 12:40 UTC (permalink / raw)
To: Emmanuel Fleury; +Cc: Michael Bellion, linux-kernel, linux-net, netdev
In-Reply-To: <4337E601.1070208@cs.aau.dk>
On Mon, 2005-26-09 at 14:13 +0200, Emmanuel Fleury wrote:
> That is right, the add/remove/modifying policies was still an issue when
> we stopped working on this. But, I think we can solve this problem by
> working on an incremental compiler. I have to admit that this require a
> proof of concept. This issue is quite critical on our method.
>
I think if you solve the lookup issue (which you seem to have) and this
you will be in good shape.
> > Several comments:
> > - Am i mistaken that your source of data is from somewhere in the
> > backbone? Would it be fair to say that something in the edge would be
> > more appropriate?
>
> The source of the data has been recorded from a backbone but all the
> clients in the experimental setting are replaying part of it and sending
> it to the gigabit switch.
>
Ok, makes sense.
> > - Is tcpreplay the right tool? What does it give you that you cant use
> > a better blaster like pktgen?
>
> The idea was to replay a realistic traffic. So we used a slightly
> modified version of the tcpreplay (I don't remember what modifications
> have been done, my co-author did it). I should definitely take a look at
> pktgen.
>
Both are useful tests. Benchmarking typically doesnt factor in realistic
- the rule of thumb being if you can win a benchmark you can do better.
The exception is when you make complex changes to win a benchmark; there
has to be a balance.
> > If you are going to run these tests in stateless firewalling as you
> > did, please consider using tc filter as well.
>
> The spirit was to test a totally new idea, the plan was not really to
> get integrated (yet) into any tool, so we did it like this. We might
> have been wrong.
I think the methodology was fine enough for what you were doing then;
academic time constraints apply and you can be forgiven for that ;->
Now that you have gone beyond academia and have some company behind your
work, it is only fair to compare against tc filter because it is in the
kernel and being used by some people.
I am willing to help consult for the tc filter side if you need help.
cheers,
jamal
^ permalink raw reply
* Re: [ANNOUNCE] Release of nf-HiPAC 0.9.0
From: Emmanuel Fleury @ 2005-09-26 12:13 UTC (permalink / raw)
To: hadi; +Cc: Michael Bellion, linux-kernel, linux-net, netdev
In-Reply-To: <1127735881.6215.294.camel@localhost.localdomain>
Hi,
jamal wrote:
>
> To repeat the tests i mentioned earlier for clarity:
> a) Variable incoming packet rate (in packets per second)
> b) Variable packet sizes
> c) Variable number of users/filters
> d) Effect of adding/removing/modifying policies while under different
> incoming traffic rates.
>
> You seem to have taken care of most of the variables involved except
> for #d below. If you look at my slides you will see why #d is
> important to have in modern firewalls. I think if you have to first
> compile rules then you will have issues, but it remains to be seen.
That is right, the add/remove/modifying policies was still an issue when
we stopped working on this. But, I think we can solve this problem by
working on an incremental compiler. I have to admit that this require a
proof of concept. This issue is quite critical on our method.
> Several comments:
> - Am i mistaken that your source of data is from somewhere in the
> backbone? Would it be fair to say that something in the edge would be
> more appropriate?
The source of the data has been recorded from a backbone but all the
clients in the experimental setting are replaying part of it and sending
it to the gigabit switch.
> - Your header extraction tool creates "10 sets of rules"; is there a
> reason for the number 10?
No particular reason.
> - Is tcpreplay the right tool? What does it give you that you cant use
> a better blaster like pktgen?
The idea was to replay a realistic traffic. So we used a slightly
modified version of the tcpreplay (I don't remember what modifications
have been done, my co-author did it). I should definitely take a look at
pktgen.
> - I think the blackbox monitor looking at the input vs output tool is
> good. It will be more complete if you can quantify the input rate then
> you can easily quantify output rate.
Interesting suggestion. Thanks.
> - While your results were useful in showing Mbps; they are incomplete
> by not mentioning the packet size. A better metric would have been
> pps. But even then mentioning packet size is also useful.
Right, the packet size was 300bytes (I think this is mentioned in the
text but not highlighted in the figures). I agree with you about pps (we
were young and innocent at the time).
> If you are going to run these tests in stateless firewalling as you
> did, please consider using tc filter as well.
The spirit was to test a totally new idea, the plan was not really to
get integrated (yet) into any tool, so we did it like this. We might
have been wrong.
Thanks for your comments.
Regards
--
Emmanuel Fleury
The highest goal of computer science is to automate that
which can be automated.
-- D. L. VerLee
^ permalink raw reply
* Re: [ANNOUNCE] Release of nf-HiPAC 0.9.0
From: jamal @ 2005-09-26 11:58 UTC (permalink / raw)
To: Emmanuel Fleury; +Cc: Michael Bellion, linux-kernel, linux-net, netdev
In-Reply-To: <4337DA7C.2000804@cs.aau.dk>
On Mon, 2005-26-09 at 13:24 +0200, Emmanuel Fleury wrote:
> Hi,
>
> Did you solved your "size" issues when entering long list of rules ???
>
> I'm still not convinced by your approach. :-/
>
> These experiments have to be updated but can you comment on this:
> http://www.cs.aau.dk/~mixxel/cf/experiments.html
To repeat the tests i mentioned earlier for clarity:
a) Variable incoming packet rate (in packets per second)
b) Variable packet sizes
c) Variable number of users/filters
d) Effect of adding/removing/modifying policies while under different
incoming traffic rates.
You seem to have taken care of most of the variables involved except for
#d below. If you look at my slides you will see why #d is important to
have in modern firewalls. I think if you have to first compile rules
then you will have issues, but it remains to be seen.
Several comments:
- Am i mistaken that your source of data is from somewhere in the
backbone? Would it be fair to say that something in the edge would be
more appropriate?
- Your header extraction tool creates "10 sets of rules"; is there a
reason for the number 10?
- Is tcpreplay the right tool? What does it give you that you cant use a
better blaster like pktgen?
- I think the blackbox monitor looking at the input vs output tool is
good. It will be more complete if you can quantify the input rate then
you can easily quantify output rate.
- While your results were useful in showing Mbps; they are incomplete by
not mentioning the packet size. A better metric would have been pps. But
even then mentioning packet size is also useful.
If you are going to run these tests in stateless firewalling as you did,
please consider using tc filter as well.
cheers,
jamal
^ permalink raw reply
* Re: [ANNOUNCE] Release of nf-HiPAC 0.9.0
From: Emmanuel Fleury @ 2005-09-26 11:24 UTC (permalink / raw)
To: Michael Bellion; +Cc: linux-kernel, linux-net, netdev
In-Reply-To: <200509260445.46740.mbellion@hipac.org>
Hi,
Did you solved your "size" issues when entering long list of rules ???
I'm still not convinced by your approach. :-/
These experiments have to be updated but can you comment on this:
http://www.cs.aau.dk/~mixxel/cf/experiments.html
Regards
--
Emmanuel Fleury
Houston, we've had a problem here.
-- Jack Swigert (Appolo XIII, April 13, 1970)
^ permalink raw reply
* Re: [ANNOUNCE] Release of nf-HiPAC 0.9.0
From: jamal @ 2005-09-26 11:18 UTC (permalink / raw)
To: Michael Bellion; +Cc: linux-kernel, linux-net, netdev
In-Reply-To: <200509260445.46740.mbellion@hipac.org>
On Mon, 2005-26-09 at 04:45 +0200, Michael Bellion wrote:
> Hi
>
> I am happy to announce the release of nf-HiPAC version 0.9.0
>
> During the development of version 0.9.0 everything was ported to Linux kernel
> 2.6 and large parts of the kernel code have been rewritten.
> The kernel patch is now fairly non-intrusive: it only adds one simple function
> to ip_tables.c. The rest of the patch introduces new files to the kernel.
> The new release fixes all known bugs and also introduces some new features.
>
> Since the last release I have become part of MARA Systems AB
> ( http://www.marasystems.com ). MARA Systems AB is now the commercial backer
> of the HiPAC Project and finances it completely. Together MARA Systems and I
> will make sure that HiPAC is actively maintained and further developed under
> the GNU GPL.
>
>
Congratulations to yourself as well as your sponsor. I think this is
useful.
The iptables wrapper is certainly valuable.
Can you post some numbers relative to iptables?
Some tests with the following parameters would be helpful:
- Variable incoming packet rate (in packets per second)
- Variable packet sizes
- Variable number of users/filters
- Effect of adding/removing/modifying policies while under different
incoming traffic rates.
Just even simple non-stateful comparisons like i did with tc over here:
http://www.suug.ch/sucon/04/slides/pkt_cls.pdf
Or even better when you do these tests also try out with tc filter.
cheers,
jamal
^ permalink raw reply
* Re: ipvs_syncmaster brings cpu to 100%
From: Horms @ 2005-09-26 8:12 UTC (permalink / raw)
To: Nishanth Aravamudan, Roger Tsang, Luca Maranzano,
LinuxVirtualServer.org users mailing list., Dave Miller,
Wensong Zhang, Julian Anastasov, netdev
In-Reply-To: <20050926080508.GF11027@verge.net.au>
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.
Luca, please test.
--
Horms
*UNTESTED*
Use msleep_interruptible() instead of ssleep() in ip_vs_sync daemon,
as the latter seems to cause 100% CPU utilistaion on HT Xeons.
Discussion:
http://archive.linuxvirtualserver.org/html/lvs-users/2005-09/msg00031.html
Reverts:
http://www.kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=commit;h=f8afb60c7537130448cc479d6d8dc9bf4ee06027
Signed-off-by: Horms <horms@verge.net.au>
diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs_sync.c
--- a/net/ipv4/ipvs/ip_vs_sync.c
+++ b/net/ipv4/ipvs/ip_vs_sync.c
@@ -655,7 +655,7 @@ static void sync_master_loop(void)
if (stop_master_sync)
break;
- ssleep(1);
+ msleep_interruptible(1000);
}
/* clean up the sync_buff queue */
@@ -712,7 +712,7 @@ static void sync_backup_loop(void)
if (stop_backup_sync)
break;
- ssleep(1);
+ msleep_interruptible(1000);
}
/* release the sending multicast socket */
@@ -824,7 +824,7 @@ static int fork_sync_thread(void *startu
if ((pid = kernel_thread(sync_thread, startup, 0)) < 0) {
IP_VS_ERR("could not create sync_thread due to %d... "
"retrying.\n", pid);
- ssleep(1);
+ msleep_interruptible(1000);
goto repeat;
}
@@ -858,7 +858,7 @@ int start_sync_thread(int state, char *m
if ((pid = kernel_thread(fork_sync_thread, &startup, 0)) < 0) {
IP_VS_ERR("could not create fork_sync_thread due to %d... "
"retrying.\n", pid);
- ssleep(1);
+ msleep_interruptible(1000);
goto repeat;
}
^ permalink raw reply
* Re: ipvs_syncmaster brings cpu to 100%
From: Horms @ 2005-09-26 8:05 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Roger Tsang, Luca Maranzano,
LinuxVirtualServer.org users mailing list., Dave Miller,
Wensong Zhang, Julian Anastasov, netdev
In-Reply-To: <20050926043400.GD5079@us.ibm.com>
On Sun, Sep 25, 2005 at 09:34:00PM -0700, Nishanth Aravamudan wrote:
> On 26.09.2005 [12:28:08 +0900], Horms wrote:
> > On Fri, Sep 23, 2005 at 11:15:31AM -0400, Roger Tsang wrote:
> > > As I've said before in this thread, you might want to try changing all the
> > > ssleep() calls to schedule_timeout().
> > >
> > > Roger
> > >
> > >
> > > On 9/22/05, Luca Maranzano <liuk001@gmail.com> wrote:
> > > >
> > > > Hello all,
> > > >
> > > > here again trying to discover the reason ot the CPU hog for
> > > > ipvs_sync{master,backup}.
> > > >
> > > > I've digged in the sources for ip_vs_sync.c and the main differences
> > > > between kernel 2.6.8 and 2.6.12 is the use of ssleep() instead of
> > > > schedule_timeout().
> > > >
> > > > The oddity I've seen is that in the header of both files, the version
> > > > is always like this:
> > > >
> > > > * Version: $Id: ip_vs_sync.c,v 1.13 2003/06/08 09:31:19 wensong Exp $
> > > > *
> > > > * Authors: Wensong Zhang <wensong@linuxvirtualserver.org>
> > > >
> > > > Is Wensong still the maintainer for this code?
> >
> > Yes, although he is kind of quiet.
> >
> > > > 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?
> In your patch, you do not need to set the state back to TASK_RUNNING,
> btw.
Thanks, updated patch below.
--
Horms
Use schedule_timeout() instead of ssleep() in ip_vs_sync daemon,
as the latter seems to cause 100% CPU utilistaion on HT Xeons.
Discussion:
http://archive.linuxvirtualserver.org/html/lvs-users/2005-09/msg00031.html
Reverts:
http://www.kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=commit;h=f8afb60c7537130448cc479d6d8dc9bf4ee06027
Signed-off-by: Horms <horms@verge.net.au>
diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs_sync.c
--- a/net/ipv4/ipvs/ip_vs_sync.c
+++ b/net/ipv4/ipvs/ip_vs_sync.c
@@ -655,7 +655,8 @@ static void sync_master_loop(void)
if (stop_master_sync)
break;
- ssleep(1);
+ __set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
}
/* clean up the sync_buff queue */
@@ -712,7 +713,8 @@ static void sync_backup_loop(void)
if (stop_backup_sync)
break;
- ssleep(1);
+ __set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
}
/* release the sending multicast socket */
@@ -824,7 +826,8 @@ static int fork_sync_thread(void *startu
if ((pid = kernel_thread(sync_thread, startup, 0)) < 0) {
IP_VS_ERR("could not create sync_thread due to %d... "
"retrying.\n", pid);
- ssleep(1);
+ __set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
goto repeat;
}
@@ -858,7 +861,8 @@ int start_sync_thread(int state, char *m
if ((pid = kernel_thread(fork_sync_thread, &startup, 0)) < 0) {
IP_VS_ERR("could not create fork_sync_thread due to %d... "
"retrying.\n", pid);
- ssleep(1);
+ __set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
goto repeat;
}
^ permalink raw reply
* Re: ipvs_syncmaster brings cpu to 100%
From: Nishanth Aravamudan @ 2005-09-26 4:34 UTC (permalink / raw)
To: Roger Tsang, Luca Maranzano,
LinuxVirtualServer.org users mailing list., Dave Miller,
Wensong Zhang, Julian Anastasov, netdev
In-Reply-To: <20050926032807.GI18357@verge.net.au>
On 26.09.2005 [12:28:08 +0900], Horms wrote:
> On Fri, Sep 23, 2005 at 11:15:31AM -0400, Roger Tsang wrote:
> > As I've said before in this thread, you might want to try changing all the
> > ssleep() calls to schedule_timeout().
> >
> > Roger
> >
> >
> > On 9/22/05, Luca Maranzano <liuk001@gmail.com> wrote:
> > >
> > > Hello all,
> > >
> > > here again trying to discover the reason ot the CPU hog for
> > > ipvs_sync{master,backup}.
> > >
> > > I've digged in the sources for ip_vs_sync.c and the main differences
> > > between kernel 2.6.8 and 2.6.12 is the use of ssleep() instead of
> > > schedule_timeout().
> > >
> > > The oddity I've seen is that in the header of both files, the version
> > > is always like this:
> > >
> > > * Version: $Id: ip_vs_sync.c,v 1.13 2003/06/08 09:31:19 wensong Exp $
> > > *
> > > * Authors: Wensong Zhang <wensong@linuxvirtualserver.org>
> > >
> > > Is Wensong still the maintainer for this code?
>
> Yes, although he is kind of quiet.
>
> > > 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?
Care to try to use msleep_interruptible() instead of ssleep(), as
opposed to schedule_timeout()?
In your patch, you do not need to set the state back to TASK_RUNNING,
btw.
Thanks,
Nish
^ permalink raw reply
* Re: ipvs_syncmaster brings cpu to 100%
From: Horms @ 2005-09-26 3:28 UTC (permalink / raw)
To: Roger Tsang, Luca Maranzano,
LinuxVirtualServer.org users mailing list.
Cc: Nishanth Aravamudan, Dave Miller, Wensong Zhang, Julian Anastasov,
netdev
In-Reply-To: <498263350509230815eb08a73@mail.gmail.com>
On Fri, Sep 23, 2005 at 11:15:31AM -0400, Roger Tsang wrote:
> As I've said before in this thread, you might want to try changing all the
> ssleep() calls to schedule_timeout().
>
> Roger
>
>
> On 9/22/05, Luca Maranzano <liuk001@gmail.com> wrote:
> >
> > Hello all,
> >
> > here again trying to discover the reason ot the CPU hog for
> > ipvs_sync{master,backup}.
> >
> > I've digged in the sources for ip_vs_sync.c and the main differences
> > between kernel 2.6.8 and 2.6.12 is the use of ssleep() instead of
> > schedule_timeout().
> >
> > The oddity I've seen is that in the header of both files, the version
> > is always like this:
> >
> > * Version: $Id: ip_vs_sync.c,v 1.13 2003/06/08 09:31:19 wensong Exp $
> > *
> > * Authors: Wensong Zhang <wensong@linuxvirtualserver.org>
> >
> > Is Wensong still the maintainer for this code?
Yes, although he is kind of quiet.
> > 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.
I have CCed him, Dave Miller, Wensong Zhang, Julian Anastasov, and the
netdev list for comment.
Could intererested parties please test the patch.
Thanks
--
Horms
Use schedule_timeout() instead of ssleep() in ip_vs_sync daemon,
as the latter seems to cause 100% CPU utilistaion on HT Xeons.
Discussion:
http://archive.linuxvirtualserver.org/html/lvs-users/2005-09/msg00031.html
Reverts:
http://www.kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=commit;h=f8afb60c7537130448cc479d6d8dc9bf4ee06027
Signed-off-by: Horms <horms@verge.net.au>
diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs_sync.c
--- a/net/ipv4/ipvs/ip_vs_sync.c
+++ b/net/ipv4/ipvs/ip_vs_sync.c
@@ -655,7 +655,9 @@ static void sync_master_loop(void)
if (stop_master_sync)
break;
- ssleep(1);
+ __set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ __set_current_state(TASK_RUNNING);
}
/* clean up the sync_buff queue */
@@ -712,7 +714,9 @@ static void sync_backup_loop(void)
if (stop_backup_sync)
break;
- ssleep(1);
+ __set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ __set_current_state(TASK_RUNNING);
}
/* release the sending multicast socket */
@@ -824,7 +828,9 @@ static int fork_sync_thread(void *startu
if ((pid = kernel_thread(sync_thread, startup, 0)) < 0) {
IP_VS_ERR("could not create sync_thread due to %d... "
"retrying.\n", pid);
- ssleep(1);
+ __set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ __set_current_state(TASK_RUNNING);
goto repeat;
}
@@ -858,7 +864,9 @@ int start_sync_thread(int state, char *m
if ((pid = kernel_thread(fork_sync_thread, &startup, 0)) < 0) {
IP_VS_ERR("could not create fork_sync_thread due to %d... "
"retrying.\n", pid);
- ssleep(1);
+ __set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ __set_current_state(TASK_RUNNING);
goto repeat;
}
^ permalink raw reply
* [ANNOUNCE] Release of nf-HiPAC 0.9.0
From: Michael Bellion @ 2005-09-26 2:45 UTC (permalink / raw)
To: linux-kernel, linux-net, netdev
Hi
I am happy to announce the release of nf-HiPAC version 0.9.0
During the development of version 0.9.0 everything was ported to Linux kernel
2.6 and large parts of the kernel code have been rewritten.
The kernel patch is now fairly non-intrusive: it only adds one simple function
to ip_tables.c. The rest of the patch introduces new files to the kernel.
The new release fixes all known bugs and also introduces some new features.
Since the last release I have become part of MARA Systems AB
( http://www.marasystems.com ). MARA Systems AB is now the commercial backer
of the HiPAC Project and finances it completely. Together MARA Systems and I
will make sure that HiPAC is actively maintained and further developed under
the GNU GPL.
For all of you who don't know nf-HiPAC yet, here is a short overview:
nf-HiPAC is a full featured packet filter for Linux which demonstrates the
power and flexibility of HiPAC. HiPAC is a novel framework for packet
classification which uses an advanced algorithm to reduce the number of
memory lookups per packet. It is ideal for environments involving large rule
sets and/or high bandwidth networks.
nf-HiPAC provides the same rich feature set as iptables, the popular Linux
packet filter. The complexity of the sophisticated HiPAC packet
classification algorithm is hidden behind an iptables compatible user
interface which renders nf-HiPAC a drop-in replacement for iptables. Thereby,
the iptables' semantics of the rules is preserved, i.e. you can construct your
rules like you are used to. From a user's point of view there is no need to
understand anything about the HiPAC algorithm.
The nf-hipac user space tool is designed to be as compatible as possible to
'iptables -t filter'. It even supports the full power of iptables targets,
matches and stateful packet filtering (connection tracking) besides the native
nf-HiPAC matches. This makes a switch from iptables to nf-HiPAC very easy.
Usually it is sufficient to replace the calls to iptables with calls to
nf-hipac for your filter rules.
Why another packet filter?
Performance:
iptables, like most packet filters, uses a simple packet classification
algorithm which traverses the rules in a chain linearly per packet until a
matching rule is found (or not). Clearly, this approach lacks efficiency.
As networks grow more and more complex and offer a wider bandwidth linear
packet filtering is no longer an option if many rules have to be matched
per packet. Higher bandwidth means more packets per second which leads to
shorter process times per packet. nf-HiPAC outperforms iptables regardless
of the number of rules, i.e. the HiPAC classification engine does not
impose any overhead even for very small rule sets.
Scalability to large rule sets:
The performance of nf-HiPAC is nearly independent of the number of rules.
nf-HiPAC with thousands of rules still outperforms iptables with 20 rules.
Dynamic rule sets:
nf-HiPAC offers fast dynamic rules et updates without stalling packet
classification in contrast to iptables which yields bad update performance
along with stalled packet processing during updates.
More information about the project can be found at: http://www.hipac.org
The releases are published on: http://sourceforge.net/projects/nf-hipac/
Enjoy,
+---------------------------+
| Michael Bellion |
| <mbellion@hipac.org> |
+---------------------------+
^ permalink raw reply
* Re: rwlock recursion on CPU#0, netfilter related?
From: Pekka Pietikainen @ 2005-09-25 20:19 UTC (permalink / raw)
To: Harald Welte; +Cc: netdev
In-Reply-To: <20050925134344.GJ731@sunbeam.de.gnumonks.org>
On Sun, Sep 25, 2005 at 03:43:44PM +0200, Harald Welte wrote:
> 1) how does your kernel .config look like?
http://cvs.fedora.redhat.com/viewcvs/devel/kernel/configs/config-generic?rev=1.60&view=auto
http://cvs.fedora.redhat.com/viewcvs/devel/kernel/configs/config-x86_64-generic?rev=1.16&view=auto
> 2) which modules are loaded
Module Size Used by
w83627hf 46569 0
eeprom 17617 0
i2c_sensor 12225 2 w83627hf,eeprom
i2c_isa 11329 0
rfcomm 61033 0
l2cap 46145 5 rfcomm
bluetooth 73317 4 rfcomm,l2cap
ipv6 325889 16
ppp_synctty 21057 0
ppp_async 22465 1
crc_ccitt 10817 1 ppp_async
ppp_generic 41953 6 ppp_synctty,ppp_async
slhc 16193 1 ppp_generic
ip_conntrack_ftp 82177 0
ipt_ULOG 18913 1
ipt_state 10689 18
ip_conntrack 60053 2 ip_conntrack_ftp,ipt_state
iptable_filter 11969 1
ip_tables 32193 3 ipt_ULOG,ipt_state,iptable_filter
loop 26449 0
video 27977 0
button 16481 0
battery 19657 0
ac 14409 0
ohci1394 46753 0
ieee1394 381273 1 ohci1394
ohci_hcd 33249 0
ehci_hcd 46157 0
parport_pc 40621 0
parport 52557 1 parport_pc
i2c_nforce2 16833 0
i2c_core 34241 5 w83627hf,eeprom,i2c_sensor,i2c_isa,i2c_nforce2
shpchp 108009 0
emu10k1_gp 12865 0
gameport 27089 2 emu10k1_gp
snd_emu10k1 138629 0
snd_rawmidi 39521 1 snd_emu10k1
snd_util_mem 14401 1 snd_emu10k1
snd_hwdep 20321 1 snd_emu10k1
snd_intel8x0 46273 0
snd_ac97_codec 106757 2 snd_emu10k1,snd_intel8x0
snd_seq_dummy 12869 0
snd_seq_oss 47012 0
snd_seq_midi_event 17473 1 snd_seq_oss
snd_seq 74265 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device 19281 5 snd_emu10k1,snd_rawmidi,snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss 68465 0
snd_mixer_oss 28225 1 snd_pcm_oss
snd_pcm 115401 4 snd_emu10k1,snd_intel8x0,snd_ac97_codec,snd_pcm_oss
snd_timer 37577 3 snd_emu10k1,snd_seq,snd_pcm
snd 75681 12 snd_emu10k1,snd_rawmidi,snd_hwdep,snd_intel8x0,snd_ac97_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore 19809 1 snd
snd_page_alloc 21713 3 snd_emu10k1,snd_intel8x0,snd_pcm
r8169 43209 0
forcedeth 30657 0
floppy 77865 0
dm_snapshot 26369 0
dm_zero 10817 0
dm_mirror 32433 0
ext3 154577 3
jbd 76145 1 ext3
dm_mod 73873 7 dm_snapshot,dm_zero,dm_mirror
sata_nv 19141 3
libata 61649 1 sata_nv
sd_mod 29121 4
scsi_mod 167801 2 libata,sd_mod
> 3) how does your ruleset look like?
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -i eth1 -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-request -j ACCEPT
-A RH-Firewall-1-INPUT -p esp -j ACCEPT
-A RH-Firewall-1-INPUT -p ah -j ACCEPT
-A RH-Firewall-1-INPUT -p ipv6 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -j ULOG
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport x -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport y -j ACCEPT
(for a bunch of ports, some with -s sourcenet/24 etc.)
-A RH-Firewall-1-INPUT -j DROP
COMMIT
# Completed on Sun Sep 28 10:37:44 2003
So basically a single-host firewall with ULOG and ftp conntracking being the
only fancy things.
> 4) most importantly, have you enabled CONFIG_IP_NF_CONNTRACK_EVENTS ?
> if yes, please disable, it's broken, a fix has been submitted, but I
> don't know if it has propagated to Linus yet (netdev Message-ID:
> <20050922143515.GD8917@rama.de.gnumonks.org>)
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:
commit 1dfbab59498d6f227c91988bab6c71af049a5333
tree 6b20409a232ebe8c37f16d06b3fbcde6bec8f328
parent a82b748930fce0dab22c64075c38c830ae116904
author Harald Welte <laforge@netfilter.org> Thu, 22 Sep 2005 23:46:57 -0700
committer David S. Miller <davem@davemloft.net> Thu, 22 Sep 2005 23:46:57
-0700
[NETFILTER] Fix conntrack event cache deadlock/oops
Which is this patch, right? Will verify whether disabling the option makes any
difference tomorrow, as well as your other recommendations.
> Also, I have that Ping time problem on my x86_64 debian unstable (smp).
> 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.
^ permalink raw reply
* Re: [PATCH/RFC] [NETFILTER]: Fix invalid module autoloading by splitting iptable_nat
From: Harald Welte @ 2005-09-25 16:44 UTC (permalink / raw)
To: Patrick McHardy
Cc: Linux Netdev List, Netfilter Development Mailinglist,
David Miller
In-Reply-To: <4336CFB4.6060806@trash.net>
[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]
On Sun, Sep 25, 2005 at 06:26:28PM +0200, Patrick McHardy wrote:
> Harald Welte wrote:
> >Hi Patrick, Dave,
> >I think we really need a solution for the last (known) remaining
> >dependency problem with 2.6.14. Please see the description
> >below. I _think_ the patch is fine, at least I couldn't find any case
> >where we could leak anything by splitting the code in two modules.
> >There's a slight semantic change, though. If the user unloads
> >iptable_nat, all existing connections (including their configured NAT
> >mappings) will continue to work. Only when ip_nat.ko is unloaded, the
> >NAT mappings are evicted from the conntrack table. I like it that way,
> >since it's logical.
>
> I agree, its more logical than having the table and the conntrack
> part in one module.
Ok. Gandalf has reviewed the code, too. This makes three to blame if
something goes wrong ;)
Dave, please apply
(sorry for the missing Signed-off-by: Harald Welte <laforge@netfilter.org>)
--
- 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/RFC] [NETFILTER]: Fix invalid module autoloading by splitting iptable_nat
From: Patrick McHardy @ 2005-09-25 16:26 UTC (permalink / raw)
To: Harald Welte
Cc: Linux Netdev List, Patrick McHardy,
Netfilter Development Mailinglist, David Miller
In-Reply-To: <20050925150755.GK731@sunbeam.de.gnumonks.org>
Harald Welte wrote:
> Hi Patrick, Dave,
>
> I think we really need a solution for the last (known) remaining
> dependency problem with 2.6.14. Please see the description
> below. I _think_ the patch is fine, at least I couldn't find any case
> where we could leak anything by splitting the code in two modules.
>
> There's a slight semantic change, though. If the user unloads
> iptable_nat, all existing connections (including their configured NAT
> mappings) will continue to work. Only when ip_nat.ko is unloaded, the
> NAT mappings are evicted from the conntrack table. I like it that way,
> since it's logical.
I agree, its more logical than having the table and the conntrack
part in one module.
^ permalink raw reply
* [PATCH/RFC] [NETFILTER]: Fix invalid module autoloading by splitting iptable_nat
From: Harald Welte @ 2005-09-25 15:07 UTC (permalink / raw)
To: Patrick McHardy
Cc: Linux Netdev List, Netfilter Development Mailinglist,
David Miller
[-- Attachment #1: Type: text/plain, Size: 11911 bytes --]
Hi Patrick, Dave,
I think we really need a solution for the last (known) remaining
dependency problem with 2.6.14. Please see the description
below. I _think_ the patch is fine, at least I couldn't find any case
where we could leak anything by splitting the code in two modules.
There's a slight semantic change, though. If the user unloads
iptable_nat, all existing connections (including their configured NAT
mappings) will continue to work. Only when ip_nat.ko is unloaded, the
NAT mappings are evicted from the conntrack table. I like it that way,
since it's logical.
If Patrick has no objections, I vote for inclusion in 2.6.14.
Thanks!
[NETFILTER]: Fix invalid module autoloading by splitting iptable_nat
When you've enabled conntrack and NAT as a module (standard case in all
distributions), and you've also enabled the new conntrack netlink
interface, loading ip_conntrack_netlink.ko will auto-load iptable_nat.ko.
This causes a huge performance penalty, since for every packet you iterate
the nat code, even if you don't want it.
This patch splits iptable_nat.ko into the NAT core (ip_nat.ko) and the
iptables frontend (iptable_nat.ko). Threfore, ip_conntrack_netlink.ko will
only pull ip_nat.ko, but not the frontend. ip_nat.ko will "only" allocate
some resources, but not affect runtime performance.
This separation is also a nice step in anticipation of new packet filters
(nf-hipac, ipset, pkttables) being able to use the NAT core.
---
commit 5ad0f056192213b2f6ac9910f754be9e6abea574
tree b06756b046853df61b39139ae58d49d0ca84274c
parent 1699521ab4e23ba4dd9f8bdd894393b8e109fe43
author Harald Welte <laforge@hanuman.de.gnumonks.org> Sun, 25 Sep 2005 17:01:38 +0200
committer Harald Welte <laforge@hanuman.de.gnumonks.org> Sun, 25 Sep 2005 17:01:38 +0200
include/linux/netfilter_ipv4/ip_nat_core.h | 12 ++++------
net/ipv4/netfilter/Makefile | 5 ++--
net/ipv4/netfilter/ip_nat_core.c | 35 +++++++++++++++++++---------
net/ipv4/netfilter/ip_nat_helper.c | 4 +++
net/ipv4/netfilter/ip_nat_standalone.c | 25 +++-----------------
5 files changed, 40 insertions(+), 41 deletions(-)
diff --git a/include/linux/netfilter_ipv4/ip_nat_core.h b/include/linux/netfilter_ipv4/ip_nat_core.h
--- a/include/linux/netfilter_ipv4/ip_nat_core.h
+++ b/include/linux/netfilter_ipv4/ip_nat_core.h
@@ -5,16 +5,14 @@
/* This header used to share core functionality between the standalone
NAT module, and the compatibility layer's use of NAT for masquerading. */
-extern int ip_nat_init(void);
-extern void ip_nat_cleanup(void);
-extern unsigned int nat_packet(struct ip_conntrack *ct,
+extern unsigned int ip_nat_packet(struct ip_conntrack *ct,
enum ip_conntrack_info conntrackinfo,
unsigned int hooknum,
struct sk_buff **pskb);
-extern int icmp_reply_translation(struct sk_buff **pskb,
- struct ip_conntrack *ct,
- enum ip_nat_manip_type manip,
- enum ip_conntrack_dir dir);
+extern int ip_nat_icmp_reply_translation(struct sk_buff **pskb,
+ struct ip_conntrack *ct,
+ enum ip_nat_manip_type manip,
+ enum ip_conntrack_dir dir);
#endif /* _IP_NAT_CORE_H */
diff --git a/net/ipv4/netfilter/Makefile b/net/ipv4/netfilter/Makefile
--- a/net/ipv4/netfilter/Makefile
+++ b/net/ipv4/netfilter/Makefile
@@ -4,7 +4,8 @@
# objects for the standalone - connection tracking / NAT
ip_conntrack-objs := ip_conntrack_standalone.o ip_conntrack_core.o ip_conntrack_proto_generic.o ip_conntrack_proto_tcp.o ip_conntrack_proto_udp.o ip_conntrack_proto_icmp.o
-iptable_nat-objs := ip_nat_standalone.o ip_nat_rule.o ip_nat_core.o ip_nat_helper.o ip_nat_proto_unknown.o ip_nat_proto_tcp.o ip_nat_proto_udp.o ip_nat_proto_icmp.o
+ip_nat-objs := ip_nat_core.o ip_nat_helper.o ip_nat_proto_unknown.o ip_nat_proto_tcp.o ip_nat_proto_udp.o ip_nat_proto_icmp.o
+iptable_nat-objs := ip_nat_rule.o ip_nat_standalone.o
ip_conntrack_pptp-objs := ip_conntrack_helper_pptp.o ip_conntrack_proto_gre.o
ip_nat_pptp-objs := ip_nat_helper_pptp.o ip_nat_proto_gre.o
@@ -40,7 +41,7 @@ obj-$(CONFIG_IP_NF_IPTABLES) += ip_table
# the three instances of ip_tables
obj-$(CONFIG_IP_NF_FILTER) += iptable_filter.o
obj-$(CONFIG_IP_NF_MANGLE) += iptable_mangle.o
-obj-$(CONFIG_IP_NF_NAT) += iptable_nat.o
+obj-$(CONFIG_IP_NF_NAT) += iptable_nat.o ip_nat.o
obj-$(CONFIG_IP_NF_RAW) += iptable_raw.o
# matches
diff --git a/net/ipv4/netfilter/ip_nat_core.c b/net/ipv4/netfilter/ip_nat_core.c
--- a/net/ipv4/netfilter/ip_nat_core.c
+++ b/net/ipv4/netfilter/ip_nat_core.c
@@ -74,12 +74,14 @@ ip_nat_proto_find_get(u_int8_t protonum)
return p;
}
+EXPORT_SYMBOL_GPL(ip_nat_proto_find_get);
void
ip_nat_proto_put(struct ip_nat_protocol *p)
{
module_put(p->me);
}
+EXPORT_SYMBOL_GPL(ip_nat_proto_put);
/* We keep an extra hash for each conntrack, for fast searching. */
static inline unsigned int
@@ -111,6 +113,7 @@ ip_nat_cheat_check(u_int32_t oldvalinv,
return csum_fold(csum_partial((char *)diffs, sizeof(diffs),
oldcheck^0xFFFF));
}
+EXPORT_SYMBOL(ip_nat_cheat_check);
/* Is this tuple already taken? (not by us) */
int
@@ -127,6 +130,7 @@ ip_nat_used_tuple(const struct ip_conntr
invert_tuplepr(&reply, tuple);
return ip_conntrack_tuple_taken(&reply, ignored_conntrack);
}
+EXPORT_SYMBOL(ip_nat_used_tuple);
/* If we source map this tuple so reply looks like reply_tuple, will
* that meet the constraints of range. */
@@ -347,6 +351,7 @@ ip_nat_setup_info(struct ip_conntrack *c
return NF_ACCEPT;
}
+EXPORT_SYMBOL(ip_nat_setup_info);
/* Returns true if succeeded. */
static int
@@ -387,10 +392,10 @@ manip_pkt(u_int16_t proto,
}
/* Do packet manipulations according to ip_nat_setup_info. */
-unsigned int nat_packet(struct ip_conntrack *ct,
- enum ip_conntrack_info ctinfo,
- unsigned int hooknum,
- struct sk_buff **pskb)
+unsigned int ip_nat_packet(struct ip_conntrack *ct,
+ enum ip_conntrack_info ctinfo,
+ unsigned int hooknum,
+ struct sk_buff **pskb)
{
enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo);
unsigned long statusbit;
@@ -417,12 +422,13 @@ unsigned int nat_packet(struct ip_conntr
}
return NF_ACCEPT;
}
+EXPORT_SYMBOL_GPL(ip_nat_packet);
/* Dir is direction ICMP is coming from (opposite to packet it contains) */
-int icmp_reply_translation(struct sk_buff **pskb,
- struct ip_conntrack *ct,
- enum ip_nat_manip_type manip,
- enum ip_conntrack_dir dir)
+int ip_nat_icmp_reply_translation(struct sk_buff **pskb,
+ struct ip_conntrack *ct,
+ enum ip_nat_manip_type manip,
+ enum ip_conntrack_dir dir)
{
struct {
struct icmphdr icmp;
@@ -509,6 +515,7 @@ int icmp_reply_translation(struct sk_buf
return 1;
}
+EXPORT_SYMBOL_GPL(ip_nat_icmp_reply_translation);
/* Protocol registration. */
int ip_nat_protocol_register(struct ip_nat_protocol *proto)
@@ -525,6 +532,7 @@ int ip_nat_protocol_register(struct ip_n
write_unlock_bh(&ip_nat_lock);
return ret;
}
+EXPORT_SYMBOL(ip_nat_protocol_register);
/* Noone stores the protocol anywhere; simply delete it. */
void ip_nat_protocol_unregister(struct ip_nat_protocol *proto)
@@ -536,6 +544,7 @@ void ip_nat_protocol_unregister(struct i
/* Someone could be still looking at the proto in a bh. */
synchronize_net();
}
+EXPORT_SYMBOL(ip_nat_protocol_unregister);
#if defined(CONFIG_IP_NF_CONNTRACK_NETLINK) || \
defined(CONFIG_IP_NF_CONNTRACK_NETLINK_MODULE)
@@ -582,7 +591,7 @@ EXPORT_SYMBOL_GPL(ip_nat_port_nfattr_to_
EXPORT_SYMBOL_GPL(ip_nat_port_range_to_nfattr);
#endif
-int __init ip_nat_init(void)
+static int __init ip_nat_init(void)
{
size_t i;
@@ -624,10 +633,14 @@ static int clean_nat(struct ip_conntrack
return 0;
}
-/* Not __exit: called from ip_nat_standalone.c:init_or_cleanup() --RR */
-void ip_nat_cleanup(void)
+static void __exit ip_nat_cleanup(void)
{
ip_ct_iterate_cleanup(&clean_nat, NULL);
ip_conntrack_destroyed = NULL;
vfree(bysource);
}
+
+MODULE_LICENSE("GPL");
+
+module_init(ip_nat_init);
+module_exit(ip_nat_cleanup);
diff --git a/net/ipv4/netfilter/ip_nat_helper.c b/net/ipv4/netfilter/ip_nat_helper.c
--- a/net/ipv4/netfilter/ip_nat_helper.c
+++ b/net/ipv4/netfilter/ip_nat_helper.c
@@ -199,6 +199,7 @@ ip_nat_mangle_tcp_packet(struct sk_buff
}
return 1;
}
+EXPORT_SYMBOL(ip_nat_mangle_tcp_packet);
/* Generic function for mangling variable-length address changes inside
* NATed UDP connections (like the CONNECT DATA XXXXX MESG XXXXX INDEX XXXXX
@@ -256,6 +257,7 @@ ip_nat_mangle_udp_packet(struct sk_buff
return 1;
}
+EXPORT_SYMBOL(ip_nat_mangle_udp_packet);
/* Adjust one found SACK option including checksum correction */
static void
@@ -399,6 +401,7 @@ ip_nat_seq_adjust(struct sk_buff **pskb,
return 1;
}
+EXPORT_SYMBOL(ip_nat_seq_adjust);
/* Setup NAT on this expected conntrack so it follows master. */
/* If we fail to get a free NAT slot, we'll get dropped on confirm */
@@ -425,3 +428,4 @@ void ip_nat_follow_master(struct ip_conn
/* hook doesn't matter, but it has to do destination manip */
ip_nat_setup_info(ct, &range, NF_IP_PRE_ROUTING);
}
+EXPORT_SYMBOL(ip_nat_follow_master);
diff --git a/net/ipv4/netfilter/ip_nat_standalone.c b/net/ipv4/netfilter/ip_nat_standalone.c
--- a/net/ipv4/netfilter/ip_nat_standalone.c
+++ b/net/ipv4/netfilter/ip_nat_standalone.c
@@ -108,8 +108,8 @@ ip_nat_fn(unsigned int hooknum,
case IP_CT_RELATED:
case IP_CT_RELATED+IP_CT_IS_REPLY:
if ((*pskb)->nh.iph->protocol == IPPROTO_ICMP) {
- if (!icmp_reply_translation(pskb, ct, maniptype,
- CTINFO2DIR(ctinfo)))
+ if (!ip_nat_icmp_reply_translation(pskb, ct, maniptype,
+ CTINFO2DIR(ctinfo)))
return NF_DROP;
else
return NF_ACCEPT;
@@ -152,7 +152,7 @@ ip_nat_fn(unsigned int hooknum,
}
IP_NF_ASSERT(info);
- return nat_packet(ct, ctinfo, hooknum, pskb);
+ return ip_nat_packet(ct, ctinfo, hooknum, pskb);
}
static unsigned int
@@ -325,15 +325,10 @@ static int init_or_cleanup(int init)
printk("ip_nat_init: can't setup rules.\n");
goto cleanup_nothing;
}
- ret = ip_nat_init();
- if (ret < 0) {
- printk("ip_nat_init: can't setup rules.\n");
- goto cleanup_rule_init;
- }
ret = nf_register_hook(&ip_nat_in_ops);
if (ret < 0) {
printk("ip_nat_init: can't register in hook.\n");
- goto cleanup_nat;
+ goto cleanup_rule_init;
}
ret = nf_register_hook(&ip_nat_out_ops);
if (ret < 0) {
@@ -374,8 +369,6 @@ static int init_or_cleanup(int init)
nf_unregister_hook(&ip_nat_out_ops);
cleanup_inops:
nf_unregister_hook(&ip_nat_in_ops);
- cleanup_nat:
- ip_nat_cleanup();
cleanup_rule_init:
ip_nat_rule_cleanup();
cleanup_nothing:
@@ -395,14 +388,4 @@ static void __exit fini(void)
module_init(init);
module_exit(fini);
-EXPORT_SYMBOL(ip_nat_setup_info);
-EXPORT_SYMBOL(ip_nat_protocol_register);
-EXPORT_SYMBOL(ip_nat_protocol_unregister);
-EXPORT_SYMBOL_GPL(ip_nat_proto_find_get);
-EXPORT_SYMBOL_GPL(ip_nat_proto_put);
-EXPORT_SYMBOL(ip_nat_cheat_check);
-EXPORT_SYMBOL(ip_nat_mangle_tcp_packet);
-EXPORT_SYMBOL(ip_nat_mangle_udp_packet);
-EXPORT_SYMBOL(ip_nat_used_tuple);
-EXPORT_SYMBOL(ip_nat_follow_master);
MODULE_LICENSE("GPL");
--
- 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: rwlock recursion on CPU#0, netfilter related?
From: Harald Welte @ 2005-09-25 13:43 UTC (permalink / raw)
To: Pekka Pietikainen; +Cc: netdev
In-Reply-To: <20050925105834.GA15243@ee.oulu.fi>
[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]
On Sun, Sep 25, 2005 at 01:58:34PM +0300, Pekka Pietikainen wrote:
> Just to get a wider audience, somewhere between 2.6.13-git4 and current
> (2.6.14-rc2-git4 is the last one I tested, which seems to have some
> fixes in this are wrt. git3, but problem remains) my x86_64
> crashes quite quickly after boot. Using Fedora devel kernels, I can
> probably whip up a vanilla kernel if the maintainers in this area
> prefer that.
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167835
Can you please give some more feedback like
1) how does your kernel .config look like?
2) which modules are loaded
3) how does your ruleset look like?
4) most importantly, have you enabled CONFIG_IP_NF_CONNTRACK_EVENTS ?
if yes, please disable, it's broken, a fix has been submitted, but I
don't know if it has propagated to Linus yet (netdev Message-ID:
<20050922143515.GD8917@rama.de.gnumonks.org>)
please also try
a) only loading iptable_filter (and ip_tables), but no other modules
a) only loading ip_conntrack but no other netfilter modules (no nat, no iptables)
b) only loading ip_conntrack and iptable_nat (but no rules)
this kind of debugging helps to locate where it is. netfilter has grown
big ;)
Also, I have that Ping time problem on my x86_64 debian unstable (smp).
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.
--
- 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
* rwlock recursion on CPU#0, netfilter related?
From: Pekka Pietikainen @ 2005-09-25 10:58 UTC (permalink / raw)
To: netdev
Just to get a wider audience, somewhere between 2.6.13-git4 and current
(2.6.14-rc2-git4 is the last one I tested, which seems to have some
fixes in this are wrt. git3, but problem remains) my x86_64
crashes quite quickly after boot. Using Fedora devel kernels, I can
probably whip up a vanilla kernel if the maintainers in this area
prefer that.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167835
and
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=119228
apart from the crashes I get funny ping times on the kernels that
break when they're still up
(64 bytes from 10.10.9.1: icmp_seq=0 ttl=255 time=4294971590968 ms)
^ permalink raw reply
* Re: [PATCH] [NETFILTER] ip_conntrack: Update event cache when status changes
From: David S. Miller @ 2005-09-24 23:56 UTC (permalink / raw)
To: laforge; +Cc: netdev, netfilter-devel
In-Reply-To: <20050924185020.GC731@sunbeam.de.gnumonks.org>
From: Harald Welte <laforge@netfilter.org>
Date: Sat, 24 Sep 2005 20:50:20 +0200
> [NETFILTER] ip_conntrack: Update event cache when status changes
>
> The GRE, SCTP and TCP protocol helpers did not call ip_conntrack_event_cache()
> when updating ct->status. This patch adds the respective calls.
>
> Signed-off-by: Harald Welte <laforge@netfilter.org>
Applied, thanks Harald.
^ permalink raw reply
* Re: [PATCH] fix NFQUEUE Kconfig dependency
From: David S. Miller @ 2005-09-24 23:52 UTC (permalink / raw)
To: laforge; +Cc: kaber, akpm, netdev, linux-kernel
In-Reply-To: <20050923150631.GH731@sunbeam.de.gnumonks.org>
From: Harald Welte <laforge@netfilter.org>
Date: Fri, 23 Sep 2005 17:06:31 +0200
> [NETFILTER]: Fix ip[6]t_NFQUEUE Kconfig dependency
>
> We have to introduce a separate Kconfig menu entry for the NFQUEUE targets.
> They cannot "just" depend on nfnetlink_queue, since nfnetlink_queue could
> be linked into the kernel, whereas iptables can be a module.
>
> Signed-off-by: Harald Welte <laforge@netfilter.org>
Applied, thanks Harald.
^ 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