2002-06-11 13:33:31

by Lev V. Vanyan

[permalink] [raw]
Subject: sysctl net.ipv4.icmp_default_ttl

-----BEGIN PGP SIGNED MESSAGE-----

I wrote a new sysctl flag allowing to control Time To Live for ICMP packages.
I've applied it to my 2.4.18 and it runs stable on fortress.mirotel.net
(Linux i386).

PS: This is my first kernel patch, so it would be better if community will
forgive me in case i've done something wrong :)


- --- linux/net/ipv4/sysctl_net_ipv4.c Wed Oct 31 01:08:12 2001
+++ linux-2.4.18/net/ipv4/sysctl_net_ipv4.c Mon Jun 10 21:51:08 2002
@@ -22,6 +22,7 @@
extern int sysctl_icmp_echo_ignore_all;
extern int sysctl_icmp_echo_ignore_broadcasts;
extern int sysctl_icmp_ignore_bogus_error_responses;
+extern int sysctl_icmp_default_ttl;

/* From ip_fragment.c */
extern int sysctl_ipfrag_low_thresh;
@@ -176,6 +177,9 @@
{NET_IPV4_ICMP_IGNORE_BOGUS_ERROR_RESPONSES,
"icmp_ignore_bogus_error_responses",
&sysctl_icmp_ignore_bogus_error_responses, sizeof(int), 0644, NULL,
&proc_dointvec},
+ {NET_IPV4_ICMP_DEFAULT_TTL, "icmp_default_ttl",
+ &sysctl_icmp_default_ttl,sizeof(int), 0644,NULL,
+ &proc_dointvec},
{NET_IPV4_ROUTE, "route", NULL, 0, 0555, ipv4_route_table},
#ifdef CONFIG_IP_MULTICAST
{NET_IPV4_IGMP_MAX_MEMBERSHIPS, "igmp_max_memberships",
- --- linux/net/ipv4/ip_output.c Thu Oct 18 00:16:39 2001
+++ linux-2.4.18/net/ipv4/ip_output.c Tue Jun 11 15:58:07 2002
@@ -84,6 +84,9 @@

int sysctl_ip_dynaddr = 0;
int sysctl_ip_default_ttl = IPDEFTTL;
+#ifdef CONFIG_SYSCTL
+extern int sysctl_icmp_default_ttl;
+#endif

/* Generate a checksum for an outgoing IP datagram. */
__inline__ void ip_send_check(struct iphdr *iph)
@@ -572,10 +575,17 @@
*/
mf = htons(IP_MF);
}
- - if (rt->rt_type == RTN_MULTICAST)
- - iph->ttl = sk->protinfo.af_inet.mc_ttl;
- - else
- - iph->ttl = sk->protinfo.af_inet.ttl;
+#ifdef CONFIG_SYSCTL
+ if(sk->protocol != IPPROTO_ICMP) {
+#endif
+ if (rt->rt_type == RTN_MULTICAST)
+ iph->ttl = sk->protinfo.af_inet.mc_ttl;
+ else
+ iph->ttl = sk->protinfo.af_inet.ttl;
+#ifdef CONFIG_SYSCTL
+ }
+ else iph->ttl = sysctl_icmp_default_ttl;
+#endif
iph->protocol = sk->protocol;
iph->check = 0;
iph->saddr = rt->rt_src;
@@ -693,10 +703,19 @@
iph->tos=sk->protinfo.af_inet.tos;
iph->tot_len = htons(length);
iph->frag_off = df;
- - iph->ttl=sk->protinfo.af_inet.mc_ttl;
+ /* set TTL for ICMP packets */
+#ifdef CONFIG_SYSCTL
+ if(iph->protocol == IPPROTO_ICMP)
+ iph->ttl = sysctl_icmp_default_ttl;
+ else {
+#endif
+ if(rt->rt_type != RTN_MULTICAST)
+ iph->ttl = sk->protinfo.af_inet.ttl;
+ else iph->ttl = sk->protinfo.af_inet.mc_ttl;
+#ifdef CONFIG_SYSCTL
+ }
+#endif
ip_select_ident(iph, &rt->u.dst, sk);
- - if (rt->rt_type != RTN_MULTICAST)
- - iph->ttl=sk->protinfo.af_inet.ttl;
iph->protocol=sk->protocol;
iph->saddr=rt->rt_src;
iph->daddr=rt->rt_dst;
- --- linux/net/ipv4/icmp.c Mon Feb 25 21:38:14 2002
+++ linux-2.4.18/net/ipv4/icmp.c Tue Jun 11 15:36:36 2002
@@ -143,6 +143,9 @@
int sysctl_icmp_echo_ignore_all;
int sysctl_icmp_echo_ignore_broadcasts;

+/* Control max icmp ttl. */
+int sysctl_icmp_default_ttl = 255;
+
/* Control parameter - ignore bogus broadcast responses? */
int sysctl_icmp_ignore_bogus_error_responses;

?

- --
Lev V. Vanyan Software Engineer
Mirotel ISP nic-hdl: VL1580-RIPE, LV2560-NIC
mailto: [email protected]
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQB1AwUBPQX8O89Sz223N4s1AQGg9wL+MvqmTeGEo+fPPQO0N9xhuDCskpOypQ/7
AoV7dkqx3IhvYqrZPFUJ2P2KYR1l/whzQK0gmFsWkc0jpPpsfW0Krtmn8JzS4U4h
PQhHhOqhbhWLOEMQoOGhkT/g/mOmAXnE
=d6XJ
-----END PGP SIGNATURE-----


2002-06-11 13:50:36

by Renato

[permalink] [raw]
Subject: Problems with e1000 driver and ksoftirqd_CPU0

Hi all,

I'm just using the latest kernel from RedHat - 2.4.18-4smp ( which I
suppose it mostly -ac series ) and I'm having real problems with an
Ethernet Gigabit network. It looks like "ksoftirqd_CPU0" eats up all the
CPU processing with a traffic of just 55 Mbps !! ( it's not my hardware...
I'm using a Dual Xeon 2Ghz and with kernel 2.4.9 it could handle easily 85
Mbps )

'vmstat 1' output:
r b w swpd free buff cache si so bi bo in cs us
sy id
0 0 1 0 1988284 2528 17052 0 0 0 0 826 352 0
16 84
0 0 0 0 1988264 2528 17052 0 0 0 0 17486 51 0
25 75
0 0 1 0 1988264 2528 17052 0 0 0 0 17661 29 0
25 75
0 0 1 0 1988264 2528 17052 0 0 0 0 17424 32 0
25 75
0 0 1 0 1988264 2528 17052 0 0 0 0 17428 42 0
25 75
0 0 1 0 1988264 2528 17052 0 0 0 0 17572 46 0
25 75

( with 2.4.9 interrupt rate was over 50.000 !! )

lsmod output:

Module Size Used by Tainted: P
ipchains 46184 162
e1000 57508 2
raid1 15780 2
aic7xxx 125440 6
sd_mod 12896 12
scsi_mod 112272 2 [aic7xxx sd_mod]

( I don't rules loaded that could impact performance )

Anybody ?

Renato - Brazil.

2002-06-11 14:04:37

by David Miller

[permalink] [raw]
Subject: Re: sysctl net.ipv4.icmp_default_ttl


What is this useful for? You can control the TTL in the APP and now
you've broken this in that you'll override the application selected
socket TTL. That is broken.

Also you messed up the patch, it is a patch of a patch instead of
before/after versions of the files.

2002-06-13 16:55:43

by Chris Leech

[permalink] [raw]
Subject: RE: Problems with e1000 driver and ksoftirqd_CPU0

Due to time constraints and wanting to have a stable and tested driver on
the distribution, Red Hat's latest kernels have the last released version of
e1000 before we started doing some major cleanup in preparation for merging
e1000 into the standard kernel distribution. One of the "features" that was
removed since then is the use of a tasklet for receive buffer allocation,
which under certain loads can be a horrible thing.

I would highly recommend trying e1000 4.2.17, either the version found in
the latest 2.5 kernels or from Intel. The version on Intel's site has some
additional backwards compatibility code for 2.2 support and a few
non-standard features that can easily be disabled at the top of the makefile
if you don't want them. On the plus side it's setup to easily build outside
of the kernel source tree if you want to test it without patching and
rebuilding the kernel.

J.A. Magallon posted a backport of the driver from 2.5 to 2.4 early last
week @ http://giga.cps.unizar.es/~magallon/linux/driver/e1000-4.2.17-k1.bz2

The latest version from Intel can always be found @
http://support.intel.com/support/go/linux/e1000.htm

--
Chris Leech <[email protected]>
Network Software Engineer
LAN Access Division, Intel Corporation

> -----Original Message-----
> From: Renato [mailto:[email protected]]
> Sent: Tuesday, June 11, 2002 3:50 AM
> To: [email protected]
> Subject: Problems with e1000 driver and ksoftirqd_CPU0
>
>
> Hi all,
>
> I'm just using the latest kernel from RedHat - 2.4.18-4smp ( which I
> suppose it mostly -ac series ) and I'm having real problems with an
> Ethernet Gigabit network. It looks like "ksoftirqd_CPU0" eats
> up all the
> CPU processing with a traffic of just 55 Mbps !! ( it's not
> my hardware...
> I'm using a Dual Xeon 2Ghz and with kernel 2.4.9 it could
> handle easily 85
> Mbps )

2002-06-13 17:03:52

by Renato

[permalink] [raw]
Subject: RE: Problems with e1000 driver and ksoftirqd_CPU0

I did the upgrade. It looks like it helped a lot. Right now I'm afraid that
I'll have a CPU bottleneck soon... Do you have any benchmark of how much
traffic, let's say on a Intel Dual Xeon 2Ghz, could handle ? Right now my
traffic is almost 100Mbps and idle processing is about 50%.

Thanks !!

On Thu, 13 Jun 2002 09:54:03 -0700, "Leech, Christopher"
<[email protected]> escreveu :

> De: "Leech, Christopher" <[email protected]>
> Data: Thu, 13 Jun 2002 09:54:03 -0700
> Para: "'Renato'" <[email protected]>, linux-
[email protected]
> Assunto: RE: Problems with e1000 driver and ksoftirqd_CPU0
>
> Due to time constraints and wanting to have a stable and tested driver on
> the distribution, Red Hat's latest kernels have the last released version
of
> e1000 before we started doing some major cleanup in preparation for
merging
> e1000 into the standard kernel distribution. One of the "features" that
was
> removed since then is the use of a tasklet for receive buffer allocation,
> which under certain loads can be a horrible thing.
>
> I would highly recommend trying e1000 4.2.17, either the version found in
> the latest 2.5 kernels or from Intel. The version on Intel's site has
some
> additional backwards compatibility code for 2.2 support and a few
> non-standard features that can easily be disabled at the top of the
makefile
> if you don't want them. On the plus side it's setup to easily build
outside
> of the kernel source tree if you want to test it without patching and
> rebuilding the kernel.
>
> J.A. Magallon posted a backport of the driver from 2.5 to 2.4 early last
> week @ http://giga.cps.unizar.es/~magallon/linux/driver/e1000-4.2.17-
k1.bz2
>
> The latest version from Intel can always be found @
> http://support.intel.com/support/go/linux/e1000.htm
>
> --
> Chris Leech <[email protected]>
> Network Software Engineer
> LAN Access Division, Intel Corporation
>
> > -----Original Message-----
> > From: Renato [mailto:[email protected]]
> > Sent: Tuesday, June 11, 2002 3:50 AM
> > To: [email protected]
> > Subject: Problems with e1000 driver and ksoftirqd_CPU0
> >
> >
> > Hi all,
> >
> > I'm just using the latest kernel from RedHat - 2.4.18-4smp ( which I
> > suppose it mostly -ac series ) and I'm having real problems with an
> > Ethernet Gigabit network. It looks like "ksoftirqd_CPU0" eats
> > up all the
> > CPU processing with a traffic of just 55 Mbps !! ( it's not
> > my hardware...
> > I'm using a Dual Xeon 2Ghz and with kernel 2.4.9 it could
> > handle easily 85
> > Mbps )
>
>
>