* Re: [RFC][NET_SCHED] explict hold dev tx lock
From: Evgeniy Polyakov @ 2007-09-17 10:27 UTC (permalink / raw)
To: jamal; +Cc: David Miller, herbert, netdev, kaber, dada1
In-Reply-To: <1189977000.4230.25.camel@localhost>
On Sun, Sep 16, 2007 at 05:10:00PM -0400, jamal (hadi@cyberus.ca) wrote:
> On Sun, 2007-16-09 at 16:52 -0400, jamal wrote:
>
> > What i should say is
> > if i grabbed the lock explicitly without disabling irqs it wont be much
> > different than what is done today and should always work.
> > No?
>
> And to be more explicit, heres a patch using the macros from previous
> patch. So far tested on 3 NICs.
How many cpu collisions you are seeing?
Did I understand you right, that you replaced trylock with lock and
thus removed collision handling and got better results?
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [RFC PATCH v0.2] net driver: mpc52xx fec
From: Sven Luther @ 2007-09-17 9:53 UTC (permalink / raw)
To: Domen Puncer; +Cc: Grant Likely, netdev, linuxppc-embedded
In-Reply-To: <20070915121444.GA19857@nd47.coderock.org>
On Sat, Sep 15, 2007 at 02:14:44PM +0200, Domen Puncer wrote:
> Updated and split version at:
> http://coderock.org/tmp/fec-v3rc1/
>
> I'll repost to lists once I run-test them.
When applying those patches, the build did die with :
ERROR: "phy_mii_ioctl" [drivers/net/fec_mpc52xx/fec_mpc52xx.ko] undefined!
Apparently, phy_mii_ioctl is not an exported symbol.
Domen, did you maybe forget a little snipplet when you cut the patches
in different pieces ? Or did i mess up applying them ?
Friendly,
Sven Luther
^ permalink raw reply
* [RFC][PATCH] trivial typo correction in net/ipv4/xfrm4_policy.c
From: Ian Brown @ 2007-09-17 7:50 UTC (permalink / raw)
To: netdev
Hello,
This is a trivial typo correction in net/ipv4/xfrm4_policy.c which
hunted my eye...
Regards,
Ian Brown
Signed-off-by: ianbrn@gmail.com
--- linux-2.6.23-rc5-clean/net/ipv4/xfrm4_policy.c 2007-09-01
09:08:24.000000000 +0300
+++ linux-2.6.23-rc5/net/ipv4/xfrm4_policy.c 2007-09-17 09:36:04.000000000 +0200
@@ -166,7 +166,7 @@
dst_prev->trailer_len = trailer_len;
memcpy(&dst_prev->metrics, &x->route->metrics, sizeof(dst_prev->metrics));
- /* Copy neighbout for reachability confirmation */
+ /* Copy neighbour for reachability confirmation */
dst_prev->neighbour = neigh_clone(rt->u.dst.neighbour);
dst_prev->input = rt->u.dst.input;
/* XXX: When IPv6 module can be unloaded, we should manage reference
^ permalink raw reply
* Re: [Bugme-new] [Bug 9031] New: TPC window is to cautious on send
From: Andrew Morton @ 2007-09-17 6:43 UTC (permalink / raw)
To: netdev; +Cc: bugme-daemon, a
In-Reply-To: <bug-9031-10286@http.bugzilla.kernel.org/>
On Sun, 16 Sep 2007 17:02:46 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9031
>
> Summary: TPC window is to cautious on send
> Product: Networking
> Version: 2.5
> KernelVersion: Any
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@osdl.org
> ReportedBy: a@oo.ms
>
>
> This has been a longstanding "bug" of sorts when talking to a system that has
> extremely small windows (under 1.5k).
>
> The only way to give the stack on the other side a nudge is to ACK twice.
>
> Here is a sample transcript, with a max window size of 1025 bytes.
>
> 18:25:43.968358 IP dr.ea.ms.http > 192.168.80.2.40246: . 37377:37633(256) ack
> 120 win 5840
> 18:25:43.992402 IP 192.168.80.2.40246 > dr.ea.ms.http: . ack 37121 win 769 <mss
> 256>
> 18:25:44.390305 IP 192.168.80.2.40246 > dr.ea.ms.http: . ack 37121 win 1025
> <mss 256>
> 18:25:44.823084 IP dr.ea.ms.http > 192.168.80.2.40246: . 37633:37889(256) ack
> 120 win 5840
>
> If I take the "nudge" code out of my IP stack, it sits for an aweful long time,
> waiting on the next packet, when there clearly is room for a few more.
>
> Should I:
> 1: Have my IP stack lie about the window till it is important?
> 2: Something else?
>
> I can't see any good reason for the large delay, since it is on a serial link,
> via SLIP.
>
> I can point you to source code that will allow you to verify the problem for
> yourself, if you would like.
>
^ permalink raw reply
* [ofa-general] Re: [PATCH 0/10 REV5] Implement skb batching and support in IPoIB/E1000
From: Krishna Kumar2 @ 2007-09-17 4:46 UTC (permalink / raw)
To: David Miller
Cc: jagana, johnpol, herbert, gaagaan, Robert.Olsson, kumarkr,
rdreier, peter.p.waskiewicz.jr, hadi, mcarlson, netdev, general,
mchan, tgraf, randy.dunlap, shemminger, kaber, sri
In-Reply-To: <20070916.192502.123919711.davem@davemloft.net>
[Removing Jeff as requested from thread :) ]
Hi Dave,
David Miller <davem@davemloft.net> wrote on 09/17/2007 07:55:02 AM:
> From: jamal <hadi@cyberus.ca>
> Date: Sun, 16 Sep 2007 22:14:21 -0400
>
> > I still think this work - despite my vested interest - needs more
> > scrutiny from a performance perspective.
>
> Absolutely.
>
> There are tertiary issues I'm personally interested in, for example
> how well this stuff works when we enable software GSO on a non-TSO
> capable card.
>
> In such a case the GSO segment should be split right before we hit the
> driver and then all the sub-segments of the original GSO frame batched
> in one shot down to the device driver.
>
> In this way you'll get a large chunk of the benefit of TSO without
> explicit hardware support for the feature.
>
> There are several cards (some even 10GB) that will benefit immensely
> from this.
I have tried this on ehca which does not support TSO. I added GSO flag at
the ipoib layer (and that resulted in a panic/fix that is mentioned in
this patchset). I will re-run tests for this and submit results.
Thanks,
- KK
^ permalink raw reply
* [PATCH][1/2] Add ICMPMsgStats MIB (RFC 4293) [RESEND]
From: David Stevens @ 2007-09-17 4:24 UTC (permalink / raw)
To: davem; +Cc: netdev, yoshfuji
[-- Attachment #1: Type: text/plain, Size: 19499 bytes --]
Dave,
Thanks. That rev2 was for v6-only; I didn't see anythng about the
v4 patch (below, in case it fell through the cracks).
+-DLS
----- Forwarded by David Stevens/Beaverton/IBM on 09/16/2007 09:02 PM
-----
David Stevens/Beaverton/IBM@IBMUS
Sent by: netdev-owner@vger.kernel.org
09/10/2007 07:25 PM
To
davem@davemloft.net, yoshfuji@linux-ipv6.org
cc
netdev@vger.kernel.org
Subject
[PATCH][1/2] Add ICMPMsgStats MIB (RFC 4293)
Background: RFC 4293 deprecates existing individual, named ICMP
type counters to be replaced with the ICMPMsgStatsTable. This table
includes entries for both IPv4 and IPv6, and requires counting of all
ICMP types, whether or not the machine implements the type.
These patches "remove" (but not really) the existing counters, and
replace them with the ICMPMsgStats tables for v4 and v6.
It includes the named counters in the /proc places they were, but gets the
values for them from the new tables. It also counts packets generated
from raw socket output (e.g., OutEchoes, MLD queries, RA's from
radvd, etc).
Changes:
1) create icmpmsg_statistics mib
2) create icmpv6msg_statistics mib
3) modify existing counters to use these
4) modify /proc/net/snmp to add "IcmpMsg" with all ICMP types
listed by number for easy SNMP parsing
5) modify /proc/net/snmp printing for "Icmp" to get the named data
from new counters.
IPv4 patch attached, IPv6 patch to follow.
+-DLS
Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
diff -ruNp linux-2.6.22.5/include/linux/snmp.h
linux-2.6.22.5_ICMPMSG/include/linux/snmp.h
--- linux-2.6.22.5/include/linux/snmp.h 2007-08-22 16:23:54.000000000
-0700
+++ linux-2.6.22.5_ICMPMSG/include/linux/snmp.h 2007-08-23
15:32:29.000000000 -0700
@@ -82,6 +82,8 @@ enum
__ICMP_MIB_MAX
};
+#define __ICMPMSG_MIB_MAX 512 /* Out+In for all 8-bit ICMP types */
+
/* icmp6 mib definitions */
/*
* RFC 2466: ICMPv6-MIB
diff -ruNp linux-2.6.22.5/include/net/icmp.h
linux-2.6.22.5_ICMPMSG/include/net/icmp.h
--- linux-2.6.22.5/include/net/icmp.h 2007-08-22 16:23:54.000000000
-0700
+++ linux-2.6.22.5_ICMPMSG/include/net/icmp.h 2007-08-23
15:56:45.000000000 -0700
@@ -30,9 +30,16 @@ struct icmp_err {
extern struct icmp_err icmp_err_convert[];
DECLARE_SNMP_STAT(struct icmp_mib, icmp_statistics);
+DECLARE_SNMP_STAT(struct icmpmsg_mib, icmpmsg_statistics);
#define ICMP_INC_STATS(field) SNMP_INC_STATS(icmp_statistics,
field)
#define ICMP_INC_STATS_BH(field) SNMP_INC_STATS_BH(icmp_statistics,
field)
#define ICMP_INC_STATS_USER(field) SNMP_INC_STATS_USER(icmp_statistics,
field)
+#define ICMPMSGOUT_INC_STATS(field) SNMP_INC_STATS(icmpmsg_statistics,
field+256)
+#define ICMPMSGOUT_INC_STATS_BH(field)
SNMP_INC_STATS_BH(icmpmsg_statistics, field+256)
+#define ICMPMSGOUT_INC_STATS_USER(field)
SNMP_INC_STATS_USER(icmpmsg_statistics, field+256)
+#define ICMPMSGIN_INC_STATS(field) SNMP_INC_STATS(icmpmsg_statistics,
field)
+#define ICMPMSGIN_INC_STATS_BH(field)
SNMP_INC_STATS_BH(icmpmsg_statistics, field)
+#define ICMPMSGIN_INC_STATS_USER(field)
SNMP_INC_STATS_USER(icmpmsg_statistics, field)
struct dst_entry;
struct net_proto_family;
@@ -42,6 +49,7 @@ extern void icmp_send(struct sk_buff *sk
extern int icmp_rcv(struct sk_buff *skb);
extern int icmp_ioctl(struct sock *sk, int cmd, unsigned long arg);
extern void icmp_init(struct net_proto_family *ops);
+extern void icmp_out_count(unsigned char type);
/* Move into dst.h ? */
extern int xrlim_allow(struct dst_entry *dst, int timeout);
diff -ruNp linux-2.6.22.5/include/net/snmp.h
linux-2.6.22.5_ICMPMSG/include/net/snmp.h
--- linux-2.6.22.5/include/net/snmp.h 2007-08-22 16:23:54.000000000
-0700
+++ linux-2.6.22.5_ICMPMSG/include/net/snmp.h 2007-08-23
14:42:50.000000000 -0700
@@ -82,6 +82,11 @@ struct icmp_mib {
unsigned long mibs[ICMP_MIB_MAX];
} __SNMP_MIB_ALIGN__;
+#define ICMPMSG_MIB_MAX __ICMPMSG_MIB_MAX
+struct icmpmsg_mib {
+ unsigned long mibs[ICMPMSG_MIB_MAX];
+} __SNMP_MIB_ALIGN__;
+
/* ICMP6 (IPv6-ICMP) */
#define ICMP6_MIB_MAX __ICMP6_MIB_MAX
struct icmpv6_mib {
diff -ruNp linux-2.6.22.5/net/ipv4/af_inet.c
linux-2.6.22.5_ICMPMSG/net/ipv4/af_inet.c
--- linux-2.6.22.5/net/ipv4/af_inet.c 2007-08-22 16:23:54.000000000
-0700
+++ linux-2.6.22.5_ICMPMSG/net/ipv4/af_inet.c 2007-08-23
14:47:26.000000000 -0700
@@ -1296,6 +1296,10 @@ static int __init init_ipv4_mibs(void)
sizeof(struct icmp_mib),
__alignof__(struct icmp_mib)) < 0)
goto err_icmp_mib;
+ if (snmp_mib_init((void **)icmpmsg_statistics,
+ sizeof(struct icmpmsg_mib),
+ __alignof__(struct icmpmsg_mib)) < 0)
+ goto err_icmpmsg_mib;
if (snmp_mib_init((void **)tcp_statistics,
sizeof(struct tcp_mib),
__alignof__(struct tcp_mib)) < 0)
@@ -1318,6 +1322,8 @@ err_udplite_mib:
err_udp_mib:
snmp_mib_free((void **)tcp_statistics);
err_tcp_mib:
+ snmp_mib_free((void **)icmpmsg_statistics);
+err_icmpmsg_mib:
snmp_mib_free((void **)icmp_statistics);
err_icmp_mib:
snmp_mib_free((void **)ip_statistics);
diff -ruNp linux-2.6.22.5/net/ipv4/icmp.c
linux-2.6.22.5_ICMPMSG/net/ipv4/icmp.c
--- linux-2.6.22.5/net/ipv4/icmp.c 2007-08-22 16:23:54.000000000
-0700
+++ linux-2.6.22.5_ICMPMSG/net/ipv4/icmp.c 2007-08-23
15:57:07.000000000 -0700
@@ -115,6 +115,7 @@ struct icmp_bxm {
* Statistics
*/
DEFINE_SNMP_STAT(struct icmp_mib, icmp_statistics) __read_mostly;
+DEFINE_SNMP_STAT(struct icmpmsg_mib, icmpmsg_statistics) __read_mostly;
/* An array of errno for error messages from dest unreach. */
/* RFC 1122: 3.2.2.1 States that NET_UNREACH, HOST_UNREACH and SR_FAILED
MUST be considered 'transient errs'. */
@@ -214,8 +215,6 @@ int sysctl_icmp_errors_use_inbound_ifadd
*/
struct icmp_control {
- int output_entry; /* Field for increment on output */
- int input_entry; /* Field for increment on input */
void (*handler)(struct sk_buff *skb);
short error; /* This ICMP is classed as an error
message */
};
@@ -316,12 +315,10 @@ out:
/*
* Maintain the counters used in the SNMP statistics for outgoing
ICMP
*/
-static void icmp_out_count(int type)
+void icmp_out_count(unsigned char type)
{
- if (type <= NR_ICMP_TYPES) {
- ICMP_INC_STATS(icmp_pointers[type].output_entry);
- ICMP_INC_STATS(ICMP_MIB_OUTMSGS);
- }
+ ICMPMSGOUT_INC_STATS(type);
+ ICMP_INC_STATS(ICMP_MIB_OUTMSGS);
}
/*
@@ -390,7 +387,6 @@ static void icmp_reply(struct icmp_bxm *
return;
icmp_param->data.icmph.checksum = 0;
- icmp_out_count(icmp_param->data.icmph.type);
inet->tos = ip_hdr(skb)->tos;
daddr = ipc.addr = rt->rt_src;
@@ -952,6 +948,7 @@ int icmp_rcv(struct sk_buff *skb)
icmph = icmp_hdr(skb);
+ ICMPMSGIN_INC_STATS_BH(icmph->type);
/*
* 18 is the highest 'known' ICMP type. Anything else is a
mystery
*
@@ -986,7 +983,6 @@ int icmp_rcv(struct sk_buff *skb)
}
}
- ICMP_INC_STATS_BH(icmp_pointers[icmph->type].input_entry);
icmp_pointers[icmph->type].handler(skb);
drop:
@@ -1002,109 +998,71 @@ error:
*/
static const struct icmp_control icmp_pointers[NR_ICMP_TYPES + 1] = {
[ICMP_ECHOREPLY] = {
- .output_entry = ICMP_MIB_OUTECHOREPS,
- .input_entry = ICMP_MIB_INECHOREPS,
.handler = icmp_discard,
},
[1] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_INERRORS,
.handler = icmp_discard,
.error = 1,
},
[2] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_INERRORS,
.handler = icmp_discard,
.error = 1,
},
[ICMP_DEST_UNREACH] = {
- .output_entry = ICMP_MIB_OUTDESTUNREACHS,
- .input_entry = ICMP_MIB_INDESTUNREACHS,
.handler = icmp_unreach,
.error = 1,
},
[ICMP_SOURCE_QUENCH] = {
- .output_entry = ICMP_MIB_OUTSRCQUENCHS,
- .input_entry = ICMP_MIB_INSRCQUENCHS,
.handler = icmp_unreach,
.error = 1,
},
[ICMP_REDIRECT] = {
- .output_entry = ICMP_MIB_OUTREDIRECTS,
- .input_entry = ICMP_MIB_INREDIRECTS,
.handler = icmp_redirect,
.error = 1,
},
[6] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_INERRORS,
.handler = icmp_discard,
.error = 1,
},
[7] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_INERRORS,
.handler = icmp_discard,
.error = 1,
},
[ICMP_ECHO] = {
- .output_entry = ICMP_MIB_OUTECHOS,
- .input_entry = ICMP_MIB_INECHOS,
.handler = icmp_echo,
},
[9] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_INERRORS,
.handler = icmp_discard,
.error = 1,
},
[10] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_INERRORS,
.handler = icmp_discard,
.error = 1,
},
[ICMP_TIME_EXCEEDED] = {
- .output_entry = ICMP_MIB_OUTTIMEEXCDS,
- .input_entry = ICMP_MIB_INTIMEEXCDS,
.handler = icmp_unreach,
.error = 1,
},
[ICMP_PARAMETERPROB] = {
- .output_entry = ICMP_MIB_OUTPARMPROBS,
- .input_entry = ICMP_MIB_INPARMPROBS,
.handler = icmp_unreach,
.error = 1,
},
[ICMP_TIMESTAMP] = {
- .output_entry = ICMP_MIB_OUTTIMESTAMPS,
- .input_entry = ICMP_MIB_INTIMESTAMPS,
.handler = icmp_timestamp,
},
[ICMP_TIMESTAMPREPLY] = {
- .output_entry = ICMP_MIB_OUTTIMESTAMPREPS,
- .input_entry = ICMP_MIB_INTIMESTAMPREPS,
.handler = icmp_discard,
},
[ICMP_INFO_REQUEST] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_DUMMY,
.handler = icmp_discard,
},
[ICMP_INFO_REPLY] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_DUMMY,
.handler = icmp_discard,
},
[ICMP_ADDRESS] = {
- .output_entry = ICMP_MIB_OUTADDRMASKS,
- .input_entry = ICMP_MIB_INADDRMASKS,
.handler = icmp_address,
},
[ICMP_ADDRESSREPLY] = {
- .output_entry = ICMP_MIB_OUTADDRMASKREPS,
- .input_entry = ICMP_MIB_INADDRMASKREPS,
.handler = icmp_address_reply,
},
};
@@ -1146,4 +1104,5 @@ void __init icmp_init(struct net_proto_f
EXPORT_SYMBOL(icmp_err_convert);
EXPORT_SYMBOL(icmp_send);
EXPORT_SYMBOL(icmp_statistics);
+EXPORT_SYMBOL(icmpmsg_statistics);
EXPORT_SYMBOL(xrlim_allow);
diff -ruNp linux-2.6.22.5/net/ipv4/ip_output.c
linux-2.6.22.5_ICMPMSG/net/ipv4/ip_output.c
--- linux-2.6.22.5/net/ipv4/ip_output.c 2007-08-22 16:23:54.000000000
-0700
+++ linux-2.6.22.5_ICMPMSG/net/ipv4/ip_output.c 2007-08-23
15:54:45.000000000 -0700
@@ -1258,6 +1258,10 @@ int ip_push_pending_frames(struct sock *
skb->priority = sk->sk_priority;
skb->dst = dst_clone(&rt->u.dst);
+ if (iph->protocol == IPPROTO_ICMP)
+ icmp_out_count(((struct icmphdr *)
+ skb_transport_header(skb))->type);
+
/* Netfilter gets whole the not fragmented skb. */
err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL,
skb->dst->dev, dst_output);
diff -ruNp linux-2.6.22.5/net/ipv4/proc.c
linux-2.6.22.5_ICMPMSG/net/ipv4/proc.c
--- linux-2.6.22.5/net/ipv4/proc.c 2007-08-22 16:23:54.000000000
-0700
+++ linux-2.6.22.5_ICMPMSG/net/ipv4/proc.c 2007-08-23
15:58:42.000000000 -0700
@@ -123,33 +123,30 @@ static const struct snmp_mib snmp4_ipext
static const struct snmp_mib snmp4_icmp_list[] = {
SNMP_MIB_ITEM("InMsgs", ICMP_MIB_INMSGS),
SNMP_MIB_ITEM("InErrors", ICMP_MIB_INERRORS),
- SNMP_MIB_ITEM("InDestUnreachs", ICMP_MIB_INDESTUNREACHS),
- SNMP_MIB_ITEM("InTimeExcds", ICMP_MIB_INTIMEEXCDS),
- SNMP_MIB_ITEM("InParmProbs", ICMP_MIB_INPARMPROBS),
- SNMP_MIB_ITEM("InSrcQuenchs", ICMP_MIB_INSRCQUENCHS),
- SNMP_MIB_ITEM("InRedirects", ICMP_MIB_INREDIRECTS),
- SNMP_MIB_ITEM("InEchos", ICMP_MIB_INECHOS),
- SNMP_MIB_ITEM("InEchoReps", ICMP_MIB_INECHOREPS),
- SNMP_MIB_ITEM("InTimestamps", ICMP_MIB_INTIMESTAMPS),
- SNMP_MIB_ITEM("InTimestampReps", ICMP_MIB_INTIMESTAMPREPS),
- SNMP_MIB_ITEM("InAddrMasks", ICMP_MIB_INADDRMASKS),
- SNMP_MIB_ITEM("InAddrMaskReps", ICMP_MIB_INADDRMASKREPS),
SNMP_MIB_ITEM("OutMsgs", ICMP_MIB_OUTMSGS),
SNMP_MIB_ITEM("OutErrors", ICMP_MIB_OUTERRORS),
- SNMP_MIB_ITEM("OutDestUnreachs", ICMP_MIB_OUTDESTUNREACHS),
- SNMP_MIB_ITEM("OutTimeExcds", ICMP_MIB_OUTTIMEEXCDS),
- SNMP_MIB_ITEM("OutParmProbs", ICMP_MIB_OUTPARMPROBS),
- SNMP_MIB_ITEM("OutSrcQuenchs", ICMP_MIB_OUTSRCQUENCHS),
- SNMP_MIB_ITEM("OutRedirects", ICMP_MIB_OUTREDIRECTS),
- SNMP_MIB_ITEM("OutEchos", ICMP_MIB_OUTECHOS),
- SNMP_MIB_ITEM("OutEchoReps", ICMP_MIB_OUTECHOREPS),
- SNMP_MIB_ITEM("OutTimestamps", ICMP_MIB_OUTTIMESTAMPS),
- SNMP_MIB_ITEM("OutTimestampReps", ICMP_MIB_OUTTIMESTAMPREPS),
- SNMP_MIB_ITEM("OutAddrMasks", ICMP_MIB_OUTADDRMASKS),
- SNMP_MIB_ITEM("OutAddrMaskReps", ICMP_MIB_OUTADDRMASKREPS),
SNMP_MIB_SENTINEL
};
+static struct {
+ char *name;
+ int index;
+} icmpmibmap[] = {
+ { "DestUnreachs", ICMP_DEST_UNREACH },
+ { "TimeExcds", ICMP_TIME_EXCEEDED },
+ { "ParmProbs", ICMP_PARAMETERPROB },
+ { "SrcQuenchs", ICMP_SOURCE_QUENCH },
+ { "Redirects", ICMP_REDIRECT },
+ { "Echos", ICMP_ECHO },
+ { "EchoReps", ICMP_ECHOREPLY },
+ { "Timestamps", ICMP_TIMESTAMP },
+ { "TimestampReps", ICMP_TIMESTAMPREPLY },
+ { "AddrMasks", ICMP_ADDRESS },
+ { "AddrMaskReps", ICMP_ADDRESSREPLY },
+ { 0, 0 }
+};
+
+
static const struct snmp_mib snmp4_tcp_list[] = {
SNMP_MIB_ITEM("RtoAlgorithm", TCP_MIB_RTOALGORITHM),
SNMP_MIB_ITEM("RtoMin", TCP_MIB_RTOMIN),
@@ -247,6 +244,72 @@ static const struct snmp_mib snmp4_net_l
SNMP_MIB_SENTINEL
};
+static void icmpmsg_put(struct seq_file *seq)
+{
+#define PERLINE 16
+
+ int j, i, count;
+ static int out[PERLINE];
+
+ count = 0;
+ for (i = 0; i < ICMPMSG_MIB_MAX; i++) {
+
+ if (snmp_fold_field((void **) icmpmsg_statistics, i))
+ out[count++] = i;
+ if (count < PERLINE)
+ continue;
+
+ seq_printf(seq, "\nIcmpMsg:");
+ for (j = 0; j < PERLINE; ++j)
+ seq_printf(seq, " %sType%u", i & 0x100 ? "Out" :
"In",
+ i & 0xff);
+ seq_printf(seq, "\nIcmpMsg: ");
+ for (j = 0; j < PERLINE; ++j)
+ seq_printf(seq, " %lu",
+ snmp_fold_field((void **)
icmpmsg_statistics,
+ out[j]));
+ seq_putc(seq, '\n');
+ }
+ if (count) {
+ seq_printf(seq, "\nIcmpMsg:");
+ for (j = 0; j < count; ++j)
+ seq_printf(seq, " %sType%u", out[j] & 0x100 ?
"Out" :
+ "In", out[j] & 0xff);
+ seq_printf(seq, "\nIcmpMsg:");
+ for (j = 0; j < count; ++j)
+ seq_printf(seq, " %lu", snmp_fold_field((void **)
+ icmpmsg_statistics, out[j]));
+ }
+
+#undef PERLINE
+}
+
+static void icmp_put(struct seq_file *seq)
+{
+ int i;
+
+ seq_puts(seq, "\nIcmp: InMsgs InErrors");
+ for (i=0; icmpmibmap[i].name != NULL; i++)
+ seq_printf(seq, " In%s", icmpmibmap[i].name);
+ seq_printf(seq, " OutMsgs OutErrors");
+ for (i=0; icmpmibmap[i].name != NULL; i++)
+ seq_printf(seq, " Out%s", icmpmibmap[i].name);
+ seq_printf(seq, "\nIcmp: %lu %lu",
+ snmp_fold_field((void **) icmp_statistics,
ICMP_MIB_INMSGS),
+ snmp_fold_field((void **) icmp_statistics,
ICMP_MIB_INERRORS));
+ for (i=0; icmpmibmap[i].name != NULL; i++)
+ seq_printf(seq, " %lu",
+ snmp_fold_field((void **) icmpmsg_statistics,
+ icmpmibmap[i].index));
+ seq_printf(seq, " %lu %lu",
+ snmp_fold_field((void **) icmp_statistics,
ICMP_MIB_OUTMSGS),
+ snmp_fold_field((void **) icmp_statistics,
ICMP_MIB_OUTERRORS));
+ for (i=0; icmpmibmap[i].name != NULL; i++)
+ seq_printf(seq, " %lu",
+ snmp_fold_field((void **) icmpmsg_statistics,
+ icmpmibmap[i].index));
+}
+
/*
* Called from the PROCfs module. This outputs /proc/net/snmp.
*/
@@ -267,15 +330,8 @@ static int snmp_seq_show(struct seq_file
snmp_fold_field((void **)ip_statistics,
snmp4_ipstats_list[i].entry));
- seq_puts(seq, "\nIcmp:");
- for (i = 0; snmp4_icmp_list[i].name != NULL; i++)
- seq_printf(seq, " %s", snmp4_icmp_list[i].name);
-
- seq_puts(seq, "\nIcmp:");
- for (i = 0; snmp4_icmp_list[i].name != NULL; i++)
- seq_printf(seq, " %lu",
- snmp_fold_field((void **)icmp_statistics,
- snmp4_icmp_list[i].entry));
+ icmp_put(seq); /* RFC 2011 compatibility */
+ icmpmsg_put(seq);
seq_puts(seq, "\nTcp:");
for (i = 0; snmp4_tcp_list[i].name != NULL; i++)
@@ -332,6 +388,8 @@ static const struct file_operations snmp
.release = single_release,
};
+
+
/*
* Output /proc/net/netstat
*/
diff -ruNp linux-2.6.22.5/net/ipv4/raw.c
linux-2.6.22.5_ICMPMSG/net/ipv4/raw.c
--- linux-2.6.22.5/net/ipv4/raw.c 2007-08-22 16:23:54.000000000
-0700
+++ linux-2.6.22.5_ICMPMSG/net/ipv4/raw.c 2007-08-23
15:54:12.000000000 -0700
@@ -313,6 +313,9 @@ static int raw_send_hdrinc(struct sock *
iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl);
}
+ if (iph->protocol == IPPROTO_ICMP)
+ icmp_out_count(((struct icmphdr *)
+ skb_transport_header(skb))->type);
err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, rt->u.dst.dev,
dst_output);
[-- Attachment #2: icmpmsgmib4.patch --]
[-- Type: application/octet-stream, Size: 14936 bytes --]
diff -ruNp linux-2.6.22.5/include/linux/snmp.h linux-2.6.22.5_ICMPMSG/include/linux/snmp.h
--- linux-2.6.22.5/include/linux/snmp.h 2007-08-22 16:23:54.000000000 -0700
+++ linux-2.6.22.5_ICMPMSG/include/linux/snmp.h 2007-08-23 15:32:29.000000000 -0700
@@ -82,6 +82,8 @@ enum
__ICMP_MIB_MAX
};
+#define __ICMPMSG_MIB_MAX 512 /* Out+In for all 8-bit ICMP types */
+
/* icmp6 mib definitions */
/*
* RFC 2466: ICMPv6-MIB
diff -ruNp linux-2.6.22.5/include/net/icmp.h linux-2.6.22.5_ICMPMSG/include/net/icmp.h
--- linux-2.6.22.5/include/net/icmp.h 2007-08-22 16:23:54.000000000 -0700
+++ linux-2.6.22.5_ICMPMSG/include/net/icmp.h 2007-08-23 15:56:45.000000000 -0700
@@ -30,9 +30,16 @@ struct icmp_err {
extern struct icmp_err icmp_err_convert[];
DECLARE_SNMP_STAT(struct icmp_mib, icmp_statistics);
+DECLARE_SNMP_STAT(struct icmpmsg_mib, icmpmsg_statistics);
#define ICMP_INC_STATS(field) SNMP_INC_STATS(icmp_statistics, field)
#define ICMP_INC_STATS_BH(field) SNMP_INC_STATS_BH(icmp_statistics, field)
#define ICMP_INC_STATS_USER(field) SNMP_INC_STATS_USER(icmp_statistics, field)
+#define ICMPMSGOUT_INC_STATS(field) SNMP_INC_STATS(icmpmsg_statistics, field+256)
+#define ICMPMSGOUT_INC_STATS_BH(field) SNMP_INC_STATS_BH(icmpmsg_statistics, field+256)
+#define ICMPMSGOUT_INC_STATS_USER(field) SNMP_INC_STATS_USER(icmpmsg_statistics, field+256)
+#define ICMPMSGIN_INC_STATS(field) SNMP_INC_STATS(icmpmsg_statistics, field)
+#define ICMPMSGIN_INC_STATS_BH(field) SNMP_INC_STATS_BH(icmpmsg_statistics, field)
+#define ICMPMSGIN_INC_STATS_USER(field) SNMP_INC_STATS_USER(icmpmsg_statistics, field)
struct dst_entry;
struct net_proto_family;
@@ -42,6 +49,7 @@ extern void icmp_send(struct sk_buff *sk
extern int icmp_rcv(struct sk_buff *skb);
extern int icmp_ioctl(struct sock *sk, int cmd, unsigned long arg);
extern void icmp_init(struct net_proto_family *ops);
+extern void icmp_out_count(unsigned char type);
/* Move into dst.h ? */
extern int xrlim_allow(struct dst_entry *dst, int timeout);
diff -ruNp linux-2.6.22.5/include/net/snmp.h linux-2.6.22.5_ICMPMSG/include/net/snmp.h
--- linux-2.6.22.5/include/net/snmp.h 2007-08-22 16:23:54.000000000 -0700
+++ linux-2.6.22.5_ICMPMSG/include/net/snmp.h 2007-08-23 14:42:50.000000000 -0700
@@ -82,6 +82,11 @@ struct icmp_mib {
unsigned long mibs[ICMP_MIB_MAX];
} __SNMP_MIB_ALIGN__;
+#define ICMPMSG_MIB_MAX __ICMPMSG_MIB_MAX
+struct icmpmsg_mib {
+ unsigned long mibs[ICMPMSG_MIB_MAX];
+} __SNMP_MIB_ALIGN__;
+
/* ICMP6 (IPv6-ICMP) */
#define ICMP6_MIB_MAX __ICMP6_MIB_MAX
struct icmpv6_mib {
diff -ruNp linux-2.6.22.5/net/ipv4/af_inet.c linux-2.6.22.5_ICMPMSG/net/ipv4/af_inet.c
--- linux-2.6.22.5/net/ipv4/af_inet.c 2007-08-22 16:23:54.000000000 -0700
+++ linux-2.6.22.5_ICMPMSG/net/ipv4/af_inet.c 2007-08-23 14:47:26.000000000 -0700
@@ -1296,6 +1296,10 @@ static int __init init_ipv4_mibs(void)
sizeof(struct icmp_mib),
__alignof__(struct icmp_mib)) < 0)
goto err_icmp_mib;
+ if (snmp_mib_init((void **)icmpmsg_statistics,
+ sizeof(struct icmpmsg_mib),
+ __alignof__(struct icmpmsg_mib)) < 0)
+ goto err_icmpmsg_mib;
if (snmp_mib_init((void **)tcp_statistics,
sizeof(struct tcp_mib),
__alignof__(struct tcp_mib)) < 0)
@@ -1318,6 +1322,8 @@ err_udplite_mib:
err_udp_mib:
snmp_mib_free((void **)tcp_statistics);
err_tcp_mib:
+ snmp_mib_free((void **)icmpmsg_statistics);
+err_icmpmsg_mib:
snmp_mib_free((void **)icmp_statistics);
err_icmp_mib:
snmp_mib_free((void **)ip_statistics);
diff -ruNp linux-2.6.22.5/net/ipv4/icmp.c linux-2.6.22.5_ICMPMSG/net/ipv4/icmp.c
--- linux-2.6.22.5/net/ipv4/icmp.c 2007-08-22 16:23:54.000000000 -0700
+++ linux-2.6.22.5_ICMPMSG/net/ipv4/icmp.c 2007-08-23 15:57:07.000000000 -0700
@@ -115,6 +115,7 @@ struct icmp_bxm {
* Statistics
*/
DEFINE_SNMP_STAT(struct icmp_mib, icmp_statistics) __read_mostly;
+DEFINE_SNMP_STAT(struct icmpmsg_mib, icmpmsg_statistics) __read_mostly;
/* An array of errno for error messages from dest unreach. */
/* RFC 1122: 3.2.2.1 States that NET_UNREACH, HOST_UNREACH and SR_FAILED MUST be considered 'transient errs'. */
@@ -214,8 +215,6 @@ int sysctl_icmp_errors_use_inbound_ifadd
*/
struct icmp_control {
- int output_entry; /* Field for increment on output */
- int input_entry; /* Field for increment on input */
void (*handler)(struct sk_buff *skb);
short error; /* This ICMP is classed as an error message */
};
@@ -316,12 +315,10 @@ out:
/*
* Maintain the counters used in the SNMP statistics for outgoing ICMP
*/
-static void icmp_out_count(int type)
+void icmp_out_count(unsigned char type)
{
- if (type <= NR_ICMP_TYPES) {
- ICMP_INC_STATS(icmp_pointers[type].output_entry);
- ICMP_INC_STATS(ICMP_MIB_OUTMSGS);
- }
+ ICMPMSGOUT_INC_STATS(type);
+ ICMP_INC_STATS(ICMP_MIB_OUTMSGS);
}
/*
@@ -390,7 +387,6 @@ static void icmp_reply(struct icmp_bxm *
return;
icmp_param->data.icmph.checksum = 0;
- icmp_out_count(icmp_param->data.icmph.type);
inet->tos = ip_hdr(skb)->tos;
daddr = ipc.addr = rt->rt_src;
@@ -952,6 +948,7 @@ int icmp_rcv(struct sk_buff *skb)
icmph = icmp_hdr(skb);
+ ICMPMSGIN_INC_STATS_BH(icmph->type);
/*
* 18 is the highest 'known' ICMP type. Anything else is a mystery
*
@@ -986,7 +983,6 @@ int icmp_rcv(struct sk_buff *skb)
}
}
- ICMP_INC_STATS_BH(icmp_pointers[icmph->type].input_entry);
icmp_pointers[icmph->type].handler(skb);
drop:
@@ -1002,109 +998,71 @@ error:
*/
static const struct icmp_control icmp_pointers[NR_ICMP_TYPES + 1] = {
[ICMP_ECHOREPLY] = {
- .output_entry = ICMP_MIB_OUTECHOREPS,
- .input_entry = ICMP_MIB_INECHOREPS,
.handler = icmp_discard,
},
[1] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_INERRORS,
.handler = icmp_discard,
.error = 1,
},
[2] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_INERRORS,
.handler = icmp_discard,
.error = 1,
},
[ICMP_DEST_UNREACH] = {
- .output_entry = ICMP_MIB_OUTDESTUNREACHS,
- .input_entry = ICMP_MIB_INDESTUNREACHS,
.handler = icmp_unreach,
.error = 1,
},
[ICMP_SOURCE_QUENCH] = {
- .output_entry = ICMP_MIB_OUTSRCQUENCHS,
- .input_entry = ICMP_MIB_INSRCQUENCHS,
.handler = icmp_unreach,
.error = 1,
},
[ICMP_REDIRECT] = {
- .output_entry = ICMP_MIB_OUTREDIRECTS,
- .input_entry = ICMP_MIB_INREDIRECTS,
.handler = icmp_redirect,
.error = 1,
},
[6] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_INERRORS,
.handler = icmp_discard,
.error = 1,
},
[7] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_INERRORS,
.handler = icmp_discard,
.error = 1,
},
[ICMP_ECHO] = {
- .output_entry = ICMP_MIB_OUTECHOS,
- .input_entry = ICMP_MIB_INECHOS,
.handler = icmp_echo,
},
[9] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_INERRORS,
.handler = icmp_discard,
.error = 1,
},
[10] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_INERRORS,
.handler = icmp_discard,
.error = 1,
},
[ICMP_TIME_EXCEEDED] = {
- .output_entry = ICMP_MIB_OUTTIMEEXCDS,
- .input_entry = ICMP_MIB_INTIMEEXCDS,
.handler = icmp_unreach,
.error = 1,
},
[ICMP_PARAMETERPROB] = {
- .output_entry = ICMP_MIB_OUTPARMPROBS,
- .input_entry = ICMP_MIB_INPARMPROBS,
.handler = icmp_unreach,
.error = 1,
},
[ICMP_TIMESTAMP] = {
- .output_entry = ICMP_MIB_OUTTIMESTAMPS,
- .input_entry = ICMP_MIB_INTIMESTAMPS,
.handler = icmp_timestamp,
},
[ICMP_TIMESTAMPREPLY] = {
- .output_entry = ICMP_MIB_OUTTIMESTAMPREPS,
- .input_entry = ICMP_MIB_INTIMESTAMPREPS,
.handler = icmp_discard,
},
[ICMP_INFO_REQUEST] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_DUMMY,
.handler = icmp_discard,
},
[ICMP_INFO_REPLY] = {
- .output_entry = ICMP_MIB_DUMMY,
- .input_entry = ICMP_MIB_DUMMY,
.handler = icmp_discard,
},
[ICMP_ADDRESS] = {
- .output_entry = ICMP_MIB_OUTADDRMASKS,
- .input_entry = ICMP_MIB_INADDRMASKS,
.handler = icmp_address,
},
[ICMP_ADDRESSREPLY] = {
- .output_entry = ICMP_MIB_OUTADDRMASKREPS,
- .input_entry = ICMP_MIB_INADDRMASKREPS,
.handler = icmp_address_reply,
},
};
@@ -1146,4 +1104,5 @@ void __init icmp_init(struct net_proto_f
EXPORT_SYMBOL(icmp_err_convert);
EXPORT_SYMBOL(icmp_send);
EXPORT_SYMBOL(icmp_statistics);
+EXPORT_SYMBOL(icmpmsg_statistics);
EXPORT_SYMBOL(xrlim_allow);
diff -ruNp linux-2.6.22.5/net/ipv4/ip_output.c linux-2.6.22.5_ICMPMSG/net/ipv4/ip_output.c
--- linux-2.6.22.5/net/ipv4/ip_output.c 2007-08-22 16:23:54.000000000 -0700
+++ linux-2.6.22.5_ICMPMSG/net/ipv4/ip_output.c 2007-08-23 15:54:45.000000000 -0700
@@ -1258,6 +1258,10 @@ int ip_push_pending_frames(struct sock *
skb->priority = sk->sk_priority;
skb->dst = dst_clone(&rt->u.dst);
+ if (iph->protocol == IPPROTO_ICMP)
+ icmp_out_count(((struct icmphdr *)
+ skb_transport_header(skb))->type);
+
/* Netfilter gets whole the not fragmented skb. */
err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL,
skb->dst->dev, dst_output);
diff -ruNp linux-2.6.22.5/net/ipv4/proc.c linux-2.6.22.5_ICMPMSG/net/ipv4/proc.c
--- linux-2.6.22.5/net/ipv4/proc.c 2007-08-22 16:23:54.000000000 -0700
+++ linux-2.6.22.5_ICMPMSG/net/ipv4/proc.c 2007-08-23 15:58:42.000000000 -0700
@@ -123,33 +123,30 @@ static const struct snmp_mib snmp4_ipext
static const struct snmp_mib snmp4_icmp_list[] = {
SNMP_MIB_ITEM("InMsgs", ICMP_MIB_INMSGS),
SNMP_MIB_ITEM("InErrors", ICMP_MIB_INERRORS),
- SNMP_MIB_ITEM("InDestUnreachs", ICMP_MIB_INDESTUNREACHS),
- SNMP_MIB_ITEM("InTimeExcds", ICMP_MIB_INTIMEEXCDS),
- SNMP_MIB_ITEM("InParmProbs", ICMP_MIB_INPARMPROBS),
- SNMP_MIB_ITEM("InSrcQuenchs", ICMP_MIB_INSRCQUENCHS),
- SNMP_MIB_ITEM("InRedirects", ICMP_MIB_INREDIRECTS),
- SNMP_MIB_ITEM("InEchos", ICMP_MIB_INECHOS),
- SNMP_MIB_ITEM("InEchoReps", ICMP_MIB_INECHOREPS),
- SNMP_MIB_ITEM("InTimestamps", ICMP_MIB_INTIMESTAMPS),
- SNMP_MIB_ITEM("InTimestampReps", ICMP_MIB_INTIMESTAMPREPS),
- SNMP_MIB_ITEM("InAddrMasks", ICMP_MIB_INADDRMASKS),
- SNMP_MIB_ITEM("InAddrMaskReps", ICMP_MIB_INADDRMASKREPS),
SNMP_MIB_ITEM("OutMsgs", ICMP_MIB_OUTMSGS),
SNMP_MIB_ITEM("OutErrors", ICMP_MIB_OUTERRORS),
- SNMP_MIB_ITEM("OutDestUnreachs", ICMP_MIB_OUTDESTUNREACHS),
- SNMP_MIB_ITEM("OutTimeExcds", ICMP_MIB_OUTTIMEEXCDS),
- SNMP_MIB_ITEM("OutParmProbs", ICMP_MIB_OUTPARMPROBS),
- SNMP_MIB_ITEM("OutSrcQuenchs", ICMP_MIB_OUTSRCQUENCHS),
- SNMP_MIB_ITEM("OutRedirects", ICMP_MIB_OUTREDIRECTS),
- SNMP_MIB_ITEM("OutEchos", ICMP_MIB_OUTECHOS),
- SNMP_MIB_ITEM("OutEchoReps", ICMP_MIB_OUTECHOREPS),
- SNMP_MIB_ITEM("OutTimestamps", ICMP_MIB_OUTTIMESTAMPS),
- SNMP_MIB_ITEM("OutTimestampReps", ICMP_MIB_OUTTIMESTAMPREPS),
- SNMP_MIB_ITEM("OutAddrMasks", ICMP_MIB_OUTADDRMASKS),
- SNMP_MIB_ITEM("OutAddrMaskReps", ICMP_MIB_OUTADDRMASKREPS),
SNMP_MIB_SENTINEL
};
+static struct {
+ char *name;
+ int index;
+} icmpmibmap[] = {
+ { "DestUnreachs", ICMP_DEST_UNREACH },
+ { "TimeExcds", ICMP_TIME_EXCEEDED },
+ { "ParmProbs", ICMP_PARAMETERPROB },
+ { "SrcQuenchs", ICMP_SOURCE_QUENCH },
+ { "Redirects", ICMP_REDIRECT },
+ { "Echos", ICMP_ECHO },
+ { "EchoReps", ICMP_ECHOREPLY },
+ { "Timestamps", ICMP_TIMESTAMP },
+ { "TimestampReps", ICMP_TIMESTAMPREPLY },
+ { "AddrMasks", ICMP_ADDRESS },
+ { "AddrMaskReps", ICMP_ADDRESSREPLY },
+ { 0, 0 }
+};
+
+
static const struct snmp_mib snmp4_tcp_list[] = {
SNMP_MIB_ITEM("RtoAlgorithm", TCP_MIB_RTOALGORITHM),
SNMP_MIB_ITEM("RtoMin", TCP_MIB_RTOMIN),
@@ -247,6 +244,72 @@ static const struct snmp_mib snmp4_net_l
SNMP_MIB_SENTINEL
};
+static void icmpmsg_put(struct seq_file *seq)
+{
+#define PERLINE 16
+
+ int j, i, count;
+ static int out[PERLINE];
+
+ count = 0;
+ for (i = 0; i < ICMPMSG_MIB_MAX; i++) {
+
+ if (snmp_fold_field((void **) icmpmsg_statistics, i))
+ out[count++] = i;
+ if (count < PERLINE)
+ continue;
+
+ seq_printf(seq, "\nIcmpMsg:");
+ for (j = 0; j < PERLINE; ++j)
+ seq_printf(seq, " %sType%u", i & 0x100 ? "Out" : "In",
+ i & 0xff);
+ seq_printf(seq, "\nIcmpMsg: ");
+ for (j = 0; j < PERLINE; ++j)
+ seq_printf(seq, " %lu",
+ snmp_fold_field((void **) icmpmsg_statistics,
+ out[j]));
+ seq_putc(seq, '\n');
+ }
+ if (count) {
+ seq_printf(seq, "\nIcmpMsg:");
+ for (j = 0; j < count; ++j)
+ seq_printf(seq, " %sType%u", out[j] & 0x100 ? "Out" :
+ "In", out[j] & 0xff);
+ seq_printf(seq, "\nIcmpMsg:");
+ for (j = 0; j < count; ++j)
+ seq_printf(seq, " %lu", snmp_fold_field((void **)
+ icmpmsg_statistics, out[j]));
+ }
+
+#undef PERLINE
+}
+
+static void icmp_put(struct seq_file *seq)
+{
+ int i;
+
+ seq_puts(seq, "\nIcmp: InMsgs InErrors");
+ for (i=0; icmpmibmap[i].name != NULL; i++)
+ seq_printf(seq, " In%s", icmpmibmap[i].name);
+ seq_printf(seq, " OutMsgs OutErrors");
+ for (i=0; icmpmibmap[i].name != NULL; i++)
+ seq_printf(seq, " Out%s", icmpmibmap[i].name);
+ seq_printf(seq, "\nIcmp: %lu %lu",
+ snmp_fold_field((void **) icmp_statistics, ICMP_MIB_INMSGS),
+ snmp_fold_field((void **) icmp_statistics, ICMP_MIB_INERRORS));
+ for (i=0; icmpmibmap[i].name != NULL; i++)
+ seq_printf(seq, " %lu",
+ snmp_fold_field((void **) icmpmsg_statistics,
+ icmpmibmap[i].index));
+ seq_printf(seq, " %lu %lu",
+ snmp_fold_field((void **) icmp_statistics, ICMP_MIB_OUTMSGS),
+ snmp_fold_field((void **) icmp_statistics, ICMP_MIB_OUTERRORS));
+ for (i=0; icmpmibmap[i].name != NULL; i++)
+ seq_printf(seq, " %lu",
+ snmp_fold_field((void **) icmpmsg_statistics,
+ icmpmibmap[i].index));
+}
+
/*
* Called from the PROCfs module. This outputs /proc/net/snmp.
*/
@@ -267,15 +330,8 @@ static int snmp_seq_show(struct seq_file
snmp_fold_field((void **)ip_statistics,
snmp4_ipstats_list[i].entry));
- seq_puts(seq, "\nIcmp:");
- for (i = 0; snmp4_icmp_list[i].name != NULL; i++)
- seq_printf(seq, " %s", snmp4_icmp_list[i].name);
-
- seq_puts(seq, "\nIcmp:");
- for (i = 0; snmp4_icmp_list[i].name != NULL; i++)
- seq_printf(seq, " %lu",
- snmp_fold_field((void **)icmp_statistics,
- snmp4_icmp_list[i].entry));
+ icmp_put(seq); /* RFC 2011 compatibility */
+ icmpmsg_put(seq);
seq_puts(seq, "\nTcp:");
for (i = 0; snmp4_tcp_list[i].name != NULL; i++)
@@ -332,6 +388,8 @@ static const struct file_operations snmp
.release = single_release,
};
+
+
/*
* Output /proc/net/netstat
*/
diff -ruNp linux-2.6.22.5/net/ipv4/raw.c linux-2.6.22.5_ICMPMSG/net/ipv4/raw.c
--- linux-2.6.22.5/net/ipv4/raw.c 2007-08-22 16:23:54.000000000 -0700
+++ linux-2.6.22.5_ICMPMSG/net/ipv4/raw.c 2007-08-23 15:54:12.000000000 -0700
@@ -313,6 +313,9 @@ static int raw_send_hdrinc(struct sock *
iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl);
}
+ if (iph->protocol == IPPROTO_ICMP)
+ icmp_out_count(((struct icmphdr *)
+ skb_transport_header(skb))->type);
err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, rt->u.dst.dev,
dst_output);
^ permalink raw reply
* [ofa-general] Re: [PATCH 1/10 REV5] [Doc] HOWTO Documentation for batching
From: Jeff Garzik @ 2007-09-17 4:13 UTC (permalink / raw)
To: Krishna Kumar2
Cc: Randy Dunlap, jagana, herbert, gaagaan, Robert.Olsson, kumarkr,
mcarlson, peter.p.waskiewicz.jr, hadi, kaber, netdev, sri,
general, mchan, tgraf, johnpol, shemminger, davem, rdreier
In-Reply-To: <OF47B92F3A.6C42637F-ON65257359.0016D45D-65257359.0016F1B4@in.ibm.com>
Please remove me from the CC list.
I get this via netdev, and not having said a single thing in the thread,
I don't feel the need to be CC'd on every email.
The CC list is pretty massive as it is, anyway.
Jeff
^ permalink raw reply
* Re: net-2.6.24 plans
From: Jeff Garzik @ 2007-09-17 4:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20070916.202258.03371690.davem@davemloft.net>
David Miller wrote:
> We've touched so much in net-2.6.24 that we really should be auditing
> the thing and fixing any bugs that have been added. If you're bored
> and looking for something to do, pick an odd NAPI driver and audit it
> in the net-2.6.24 tree.
You could try that weird "post patches on the list" thing for review.
I dunno about sparc64, but IMO any networking work you do yourself and
commit yourself should also be sent to the list for review.
Jeff
^ permalink raw reply
* Re: [PATCH 1/10 REV5] [Doc] HOWTO Documentation for batching
From: Krishna Kumar2 @ 2007-09-17 4:10 UTC (permalink / raw)
To: Randy Dunlap
Cc: davem, gaagaan, general, hadi, herbert, jagana, jeff, johnpol,
kaber, kumarkr, mcarlson, mchan, netdev, peter.p.waskiewicz.jr,
rdreier, rick.jones2, Robert.Olsson, shemminger, sri, tgraf, xma
In-Reply-To: <20070914113709.80baba4d.randy.dunlap@oracle.com>
Hi Randy,
Randy Dunlap <randy.dunlap@oracle.com> wrote on 09/15/2007 12:07:09 AM:
> > + To fix this problem, error cases where driver xmit gets called with
a
> > + skb must code as follows:
> > + 1. If driver xmit cannot get tx lock, return NETDEV_TX_LOCKED
> > + as usual. This allows qdisc to requeue the skb.
> > + 2. If driver xmit got the lock but failed to send the skb, it
> > + should return NETDEV_TX_BUSY but before that it should have
> > + queue'd the skb to the batch list. In this case, the qdisc
>
> queued
>
> > + does not requeue the skb.
Since this was a new section that I added to the documentation, this error
creeped up. Thanks for catching it, and review comments/ack-off :)
thanks,
- KK
^ permalink raw reply
* Re: [PATCH 0/10 REV5] Implement skb batching and support in IPoIB/E1000
From: Krishna Kumar2 @ 2007-09-17 4:08 UTC (permalink / raw)
To: David Miller
Cc: gaagaan, general, hadi, herbert, jagana, jeff, johnpol, kaber,
kumarkr, mcarlson, mchan, netdev, peter.p.waskiewicz.jr,
randy.dunlap, rdreier, rick.jones2, Robert.Olsson, shemminger,
sri, tgraf, xma
In-Reply-To: <20070916.161748.48388692.davem@davemloft.net>
Hi Dave,
David Miller <davem@davemloft.net> wrote on 09/17/2007 04:47:48 AM:
> The only major complaint I have about this patch series is that
> the IPoIB part should just be one big changeset. Otherwise the
> tree is not bisectable, for example the initial ipoib header file
> change breaks the build.
Right, I will change it accordingly.
> On a lower priority, I question the indirection of skb_blist by making
> it a pointer. For what? Saving 12 bytes on 64-bit? That kmalloc()'d
> thing is a nearly guarenteed cache and/or TLB miss. Just inline the
> thing, we generally don't do crap like this anywhere else.
The intention was to avoid having two flags (one that driver supports
batching and second to indicate that batching is on/off). So I could test
skb_blist as an indication of whether batching is on/off. But your point
on cache miss is absolutely correct, and I will change this part to be
inline.
thanks,
- KK
^ permalink raw reply
* Re: [PATCH 10/10 REV5] [E1000] Implement batching
From: Krishna Kumar2 @ 2007-09-17 3:56 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: davem, gaagaan, general, hadi, herbert, jagana, jeff, kaber,
kumarkr, mcarlson, mchan, netdev, peter.p.waskiewicz.jr,
randy.dunlap, rdreier, rick.jones2, Robert.Olsson, shemminger,
sri, tgraf, xma
In-Reply-To: <20070914124714.GD18517@2ka.mipt.ru>
Hi Evgeniy,
Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote on 09/14/2007 06:17:14 PM:
> > if (unlikely(skb->len <= 0)) {
> > dev_kfree_skb_any(skb);
> > - return NETDEV_TX_OK;
> > + return NETDEV_TX_DROPPED;
> > }
>
> This changes could actually go as own patch, although not sure it is
> ever used. just a though, not a stopper.
Since this flag is new and useful only for batching, I feel it is OK to
include it in this patch.
> > + if (!skb || (blist && skb_queue_len(blist))) {
> > + /*
> > + * Either batching xmit call, or single skb case but there are
> > + * skbs already in the batch list from previous failure to
> > + * xmit - send the earlier skbs first to avoid out of order.
> > + */
> > + if (skb)
> > + __skb_queue_tail(blist, skb);
> > + skb = __skb_dequeue(blist);
>
> Why is it put at the end?
There is a bug that I had explained in rev4 (see XXX below) resulting
in sending out skbs out of order. The fix is that if the driver gets
called with a skb but there are older skbs already in the batch list
(which failed to get sent out), send those skbs first before this one.
Thanks,
- KK
[XXX] Dave had suggested to use batching only in the net_tx_action case.
When I implemented that in earlier revisions, there were lots of TCP
retransmissions (about 18,000 to every 1 in regular code). I found the
reason
for part of that problem as: skbs get queue'd up in dev->qdisc (when tx
lock
was not got or queue blocked); when net_tx_action is called later, it
passes
the batch list as argument to qdisc_run and this results in skbs being
moved
to the batch list; then batching xmit also fails due to tx lock failure;
the
next many regular xmit of a single skb will go through the fast path (pass
NULL batch list to qdisc_run) and send those skbs out to the device while
previous skbs are cooling their heels in the batch list.
The first fix was to not pass NULL/batch-list to qdisc_run() but to always
check whether skbs are present in batch list when trying to xmit. This
reduced
retransmissions by a third (from 18,000 to around 12,000), but led to
another
problem while testing - iperf transmit almost zero data for higher # of
parallel flows like 64 or more (and when I run iperf for a 2 min run, it
takes about 5-6 mins, and reports that it ran 0 secs and the amount of data
transfered is a few MB's). I don't know why this happens with this being
the
only change (any ideas is very appreciated).
The second fix that resolved this was to revert back to Dave's suggestion
to
use batching only in net_tx_action case, and modify the driver to see if
skbs
are present in batch list and to send them out first before sending the
current skb. I still see huge retransmission for IPoIB (but not for E1000),
though it has reduced to 12,000 from the earlier 18,000 number.
^ permalink raw reply
* Re: [PATCH 2/10 REV5] [core] Add skb_blist & support for batching
From: Krishna Kumar2 @ 2007-09-17 3:51 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: davem, gaagaan, general, hadi, herbert, jagana, jeff, kaber,
kumarkr, mcarlson, mchan, netdev, peter.p.waskiewicz.jr,
randy.dunlap, rdreier, rick.jones2, Robert.Olsson, shemminger,
sri, tgraf, xma
In-Reply-To: <20070914124637.GC18517@2ka.mipt.ru>
Hi Evgeniy,
Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote on 09/14/2007 06:16:38 PM:
> > + if (dev->features & NETIF_F_BATCH_SKBS) {
> > + /* Driver supports batching skb */
> > + dev->skb_blist = kmalloc(sizeof *dev->skb_blist, GFP_KERNEL);
> > + if (dev->skb_blist)
> > + skb_queue_head_init(dev->skb_blist);
> > + }
> > +
>
> A nitpick is that you should use sizeof(struct ...) and I think it
> requires flag clearing in cae of failed initialization?
I thought it is better to use *var name in case the name of the structure
changes. Also, the flag is not cleared since I could try to enable batching
later, and it could succeed at that time. When skb_blist is allocated, then
batching is enabled otherwise it is disabled (while features flag just
indicates that driver supports batching).
Thanks,
- KK
^ permalink raw reply
* Re: [PATCH 3/10 REV5] [sched] Modify qdisc_run to support batching
From: Krishna Kumar2 @ 2007-09-17 3:49 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: davem, gaagaan, general, hadi, herbert, jagana, jeff, kaber,
kumarkr, mcarlson, mchan, netdev, peter.p.waskiewicz.jr,
randy.dunlap, rdreier, rick.jones2, Robert.Olsson, shemminger,
sri, tgraf, xma
In-Reply-To: <20070914121518.GB18517@2ka.mipt.ru>
Hi Evgeniy,
Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote on 09/14/2007 05:45:19 PM:
> > + if (skb->next) {
> > + int count = 0;
> > +
> > + do {
> > + struct sk_buff *nskb = skb->next;
> > +
> > + skb->next = nskb->next;
> > + __skb_queue_tail(dev->skb_blist, nskb);
> > + count++;
> > + } while (skb->next);
>
> Could it be list_move()-like function for skb lists?
> I'm pretty sure if you change first and the last skbs and ke of the
> queue in one shot, result will be the same.
I have to do a bit more like update count, etc, but I agree it is do-able.
I had mentioned in my PATCH 0/10 that I will later try this suggestion
that you provided last time.
> Actually how many skbs are usually batched in your load?
It depends, eg when the tx lock is not got, I get batching of upto 8-10
skbs (assuming that tx lock was not got quite a few times). But when the
queue gets blocked, I have seen batching upto 4K skbs (if tx_queue_len
is 4K).
> > + /* Reset destructor for kfree_skb to work */
> > + skb->destructor = DEV_GSO_CB(skb)->destructor;
> > + kfree_skb(skb);
>
> Why do you free first skb in the chain?
This is the gso code which has segmented 'skb' to skb'1-n', and those
skb'1-n' are sent out and freed by driver, which means the dummy 'skb'
(without any data) remains to be freed.
Thanks,
- KK
^ permalink raw reply
* [PATCH] Blackfin EMAC driver: add a select for the PHYLIB of this driver
From: Bryan Wu @ 2007-09-17 3:20 UTC (permalink / raw)
To: Robin Getz, jeff, akpm, linux-kernel, netdev
In-Reply-To: <200709162251.01558.rgetz@blackfin.uclinux.org>
Since we are adding requirement for the PHYLIB for this driver, there should be a select for that
Cc: Robin Getz <robin.getz@analog.com>
Signed-off-by: Bryan Wu <bryan.wu@analog.com>
---
drivers/net/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 5b9e17b..5eef224 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -843,6 +843,8 @@ config BFIN_MAC
tristate "Blackfin 536/537 on-chip mac support"
depends on NET_ETHERNET && (BF537 || BF536) && (!BF537_PORT_H)
select CRC32
+ select MII
+ select PHYLIB
select BFIN_MAC_USE_L1 if DMA_UNCACHED_NONE
help
This is the driver for blackfin on-chip mac device. Say Y if you want it
--
1.5.2
^ permalink raw reply related
* net-2.6.24 plans
From: David Miller @ 2007-09-17 3:22 UTC (permalink / raw)
To: netdev
Most if not all of my 2 week backlog of patches is in the net-2.6.24
and net-2.6 tree now. And any relevant -stable fixes will be
submitted in the next day or two.
Tomorrow (Monday) I want to rebase the net-2.6.24 tree one more time
to deal with all of the conflicts which exist between
linux-2.6/net-2.6 and net-2.6.24, but I'll likely defer that
until the net-2.6 fixes I just pushed to Linus are integrated.
It's to the point where every single bug fix put into Linus's tree
creates a merge conflict with net-2.6.24, we are simply touching that
much stuff. :-)
I expect some small network namespace fixes from Eric B., but that's
basically it as far as 2.6.24 is concerned. Oh yes, there are also
the MAC_FMT/MAC_ARG bits from Joe Perches that I need to do a merge
of.
The transmit batching stuff needs a lot more analysis and discussion,
so I definitely see that stuff as 2.6.25 material. I think if we can
avoid a food fight between Jamal and Mr. Kumar and have healthy
discussions, we can end up with a really nice implementation. So
everyone put your boxing gloves away and let's get at it. :-)
We've touched so much in net-2.6.24 that we really should be auditing
the thing and fixing any bugs that have been added. If you're bored
and looking for something to do, pick an odd NAPI driver and audit it
in the net-2.6.24 tree.
^ permalink raw reply
* Re: [PATCH 3/3] Blackfin EMAC driver: Add phyabstraction layer supporting in bfin_emac driver
From: Bryan Wu @ 2007-09-17 3:11 UTC (permalink / raw)
To: Robin Getz; +Cc: bryan.wu, jeff, akpm, linux-kernel, netdev
In-Reply-To: <200709162251.01558.rgetz@blackfin.uclinux.org>
On Sun, 2007-09-16 at 22:51 -0400, Robin Getz wrote:
> On Sat 15 Sep 2007 22:57, Bryan Wu pondered:
> >
> > - add MDIO functions and register mdio bus
> > - add phy abstraction layer (PAL) functions and use PAL API
> > - test on STAMP537 board
>
> Today, the Kconfig for the Blackfin just includes:
>
> > config BFIN_MAC
> > tristate "Blackfin 536/537 on-chip mac support"
> > depends on NET_ETHERNET && (BF537 || BF536) && (!BF537_PORT_H)
> > select CRC32
> > select BFIN_MAC_USE_L1 if DMA_UNCACHED_NONE
> > help
> > This is the driver for blackfin on-chip mac device. Say Y if you
> > want it compiled into the kernel. This driver is also available as a module
> > ( = code which can be inserted in and removed from the running kernel
> > whenever you want). The module will be called bfin_mac.
>
> Since you are adding requirement for the PHYLIB with this patch, should there
> be a select for that?
>
> -Robin
OK, I will send a patch for this update, since some people failed to
compile the kernel without select the PHYLIB.
Thanks
-Bryan Wu
^ permalink raw reply
* Re: [PATCH 0/10 REV5] Implement skb batching and support in IPoIB/E1000
From: David Miller @ 2007-09-17 3:13 UTC (permalink / raw)
To: hadi
Cc: krkumar2, johnpol, herbert, kaber, shemminger, jagana,
Robert.Olsson, rick.jones2, xma, gaagaan, netdev, rdreier,
peter.p.waskiewicz.jr, mcarlson, jeff, mchan, general, kumarkr,
tgraf, randy.dunlap, sri
In-Reply-To: <1189998103.4230.76.camel@localhost>
From: jamal <hadi@cyberus.ca>
Date: Sun, 16 Sep 2007 23:01:43 -0400
> I think GSO is still useful on top of this.
> In my patches anything with gso gets put into the batch list and shot
> down the driver. Ive never considered checking whether the nic is TSO
> capable, that may be something worth checking into. The netiron allows
> you to shove upto 128 skbs utilizing one tx descriptor, which makes for
> interesting possibilities.
We're talking past each other, but I'm happy to hear that for
sure your code does the right thing :-)
Right now only TSO capable hardware sets the TSO capable bit,
except perhaps for the XEN netfront driver.
What Herbert and I want to do is basically turn on TSO for
devices that can't do it in hardware, and rely upon the GSO
framework to do the segmenting in software right before we
hit the device.
This only makes sense for devices which can 1) scatter-gather
and 2) checksum on transmit. Otherwise we make too many
copies and/or passes over the data.
And we can only get the full benefit if we can pass all the
sub-segments down to the driver in one ->hard_start_xmit()
call.
> On a side note: My observation is that with large packets on a very busy
> system; bulk transfer type app, one approaches wire speed; with or
> without batching, the apps are mostly idling (Ive seen upto 90% idle
> time polling at the socket level for write to complete with a really
> busy system). This is the case with or without batching. cpu seems a
> little better with batching. As the aggregation of the apps gets more
> aggressive (achievable by reducing their packet sizes), one can achieve
> improved throughput and reduced cpu utilization. This all with UDP; i am
> still studying tcp.
UDP apps spraying data tend to naturally batch well and load balance
amongst themselves because each socket fills up to it's socket send
buffer limit, then sleeps, and we then get a stream from the next UDP
socket up to it's limit, and so on and so forth.
UDP is too easy a test case in fact :-)
^ permalink raw reply
* Re: [PATCH 0/10 REV5] Implement skb batching and support in IPoIB/E1000
From: jamal @ 2007-09-17 3:01 UTC (permalink / raw)
To: David Miller
Cc: krkumar2, johnpol, herbert, kaber, shemminger, jagana,
Robert.Olsson, rick.jones2, xma, gaagaan, netdev, rdreier,
peter.p.waskiewicz.jr, mcarlson, jeff, mchan, general, kumarkr,
tgraf, randy.dunlap, sri
In-Reply-To: <20070916.192502.123919711.davem@davemloft.net>
On Sun, 2007-16-09 at 19:25 -0700, David Miller wrote:
> There are tertiary issues I'm personally interested in, for example
> how well this stuff works when we enable software GSO on a non-TSO
> capable card.
>
> In such a case the GSO segment should be split right before we hit the
> driver and then all the sub-segments of the original GSO frame batched
> in one shot down to the device driver.
I think GSO is still useful on top of this.
In my patches anything with gso gets put into the batch list and shot
down the driver. Ive never considered checking whether the nic is TSO
capable, that may be something worth checking into. The netiron allows
you to shove upto 128 skbs utilizing one tx descriptor, which makes for
interesting possibilities.
> In this way you'll get a large chunk of the benefit of TSO without
> explicit hardware support for the feature.
>
> There are several cards (some even 10GB) that will benefit immensely
> from this.
indeed - ive always wondered if batching this way would make the NICs
behave differently from the way TSO does.
On a side note: My observation is that with large packets on a very busy
system; bulk transfer type app, one approaches wire speed; with or
without batching, the apps are mostly idling (Ive seen upto 90% idle
time polling at the socket level for write to complete with a really
busy system). This is the case with or without batching. cpu seems a
little better with batching. As the aggregation of the apps gets more
aggressive (achievable by reducing their packet sizes), one can achieve
improved throughput and reduced cpu utilization. This all with UDP; i am
still studying tcp.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 3/3] Blackfin EMAC driver: Add phyabstraction layer supporting in bfin_emac driver
From: Robin Getz @ 2007-09-17 2:51 UTC (permalink / raw)
To: bryan.wu; +Cc: jeff, akpm, linux-kernel, netdev
In-Reply-To: <1189911475.9901.8.camel@roc-laptop>
On Sat 15 Sep 2007 22:57, Bryan Wu pondered:
>
> - add MDIO functions and register mdio bus
> - add phy abstraction layer (PAL) functions and use PAL API
> - test on STAMP537 board
Today, the Kconfig for the Blackfin just includes:
> config BFIN_MAC
> tristate "Blackfin 536/537 on-chip mac support"
> depends on NET_ETHERNET && (BF537 || BF536) && (!BF537_PORT_H)
> select CRC32
> select BFIN_MAC_USE_L1 if DMA_UNCACHED_NONE
> help
> This is the driver for blackfin on-chip mac device. Say Y if you
> want it compiled into the kernel. This driver is also available as a module
> ( = code which can be inserted in and removed from the running kernel
> whenever you want). The module will be called bfin_mac.
Since you are adding requirement for the PHYLIB with this patch, should there
be a select for that?
-Robin
^ permalink raw reply
* Re: [v2 PATCH 8/8] SCTP: Tie ADD-IP and AUTH functionality as required by spec.
From: David Miller @ 2007-09-17 2:35 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: lksctp-developers, netdev
In-Reply-To: <1189797290519-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 14 Sep 2007 15:14:50 -0400
> [.. forgot to refresh the patch, the other version has compile problems ..]
>
> ADD-IP spec requires AUTH. It is, in fact, dangerous without AUTH.
> So, disable ADD-IP functionality if the peer claims to support
> ADD-IP, but not AUTH.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Aha, I caught this and applied the correct patch.
^ permalink raw reply
* Re: [PATCH 8/8] SCTP: Tie ADD-IP and AUTH functionality as required by spec.
From: David Miller @ 2007-09-17 2:34 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: lksctp-developers, netdev
In-Reply-To: <11897955003232-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 14 Sep 2007 14:44:59 -0400
> ADD-IP spec requires AUTH. It is, in fact, dangerous without AUTH.
> So, disable ADD-IP functionality if the peer claims to support
> ADD-IP, but not AUTH.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied to net-2.6.24, thanks.
^ permalink raw reply
* Re: [PATCH 7/8] SCTP: API updates to suport SCTP-AUTH extensions.
From: David Miller @ 2007-09-17 2:34 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: lksctp-developers, netdev
In-Reply-To: <1189795500886-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 14 Sep 2007 14:44:58 -0400
> Add SCTP-AUTH API. The API implemented here was
> agreed to between implementors at the 9th SCTP Interop.
> It will be documented in the next revision of the
> SCTP socket API spec.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied to net-2.6.24, thanks.
^ permalink raw reply
* Re: [PATCH 6/8] SCTP: Implement the receive and verification of AUTH chunk
From: David Miller @ 2007-09-17 2:33 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: lksctp-developers, netdev
In-Reply-To: <11897955003311-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 14 Sep 2007 14:44:57 -0400
> This patch implements the receive path needed to process authenticated
> chunks. Add ability to process the AUTH chunk and handle edge cases
> for authenticated COOKIE-ECHO as well.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied to net-2.6.24, thanks.
^ permalink raw reply
* Re: [PATCH 5/8] SCTP: Enable the sending of the AUTH chunk.
From: David Miller @ 2007-09-17 2:32 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: lksctp-developers, netdev
In-Reply-To: <11897955001857-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 14 Sep 2007 14:44:56 -0400
> SCTP-AUTH, Section 6.2:
>
> Endpoints MUST send all requested chunks authenticated where this has
> been requested by the peer. The other chunks MAY be sent
> authenticated or not. If endpoint pair shared keys are used, one of
> them MUST be selected for authentication.
>
> To send chunks in an authenticated way, the sender MUST include these
> chunks after an AUTH chunk. This means that a sender MUST bundle
> chunks in order to authenticate them.
>
> If the endpoint has no endpoint pair shared key for the peer, it MUST
> use Shared Key Identifier 0 with an empty endpoint pair shared key.
> If there are multiple endpoint shared keys the sender selects one and
> uses the corresponding Shared Key Identifier
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied to net-2.6.24, thanks.
^ permalink raw reply
* Re: [PATCH 4/8] SCTP: Implete SCTP-AUTH parameter processing
From: David Miller @ 2007-09-17 2:32 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: lksctp-developers, netdev
In-Reply-To: <11897954992330-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 14 Sep 2007 14:44:55 -0400
> Implement processing for the CHUNKS, RANDOM, and HMAC parameters and
> deal with how this parameters are effected by association restarts.
> In particular, during unexpeted INIT processing, we need to reply with
> parameters from the original INIT chunk. Also, after restart, we need
> to update the old association with new peer parameters and change the
> association shared keys.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied to net-2.6.24, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox