* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: Alan Cox @ 2010-03-26 16:02 UTC (permalink / raw)
To: Richard Hartmann; +Cc: linux-kernel, netdev, linux-ppp
In-Reply-To: <2d460de71003260850x7f90d04cy79ac853464108182@mail.gmail.com>
> We are fully aware that this code is not nearly up for inclusion into
> the kernel. What we hope to achieve is that someone with the skills to
> do this properly will introduce an option to turn off fragmentation on
> PPP multi-link or to just do away with it completely.
You should be able to manage that I'm sure:
The main thing will be to take this chunk, strip out the // stuff and
then make it a function of its own so you've got clean code in the main
path of the form
#ifdef CONFIG_PPP_MULTILINK
if (ml_explode) {
if (!ppp_mp_explode(...)
..
} else {
ppp_mp_roundrobin(...)
}
and your bits as a new routine. You can then do this
static int ml_explode = 1;
module_param(ml_explode, int, 0600);
MODULE_PARM_DESC(ml_expode, "Set this to zero to disabling multilink \
fragmentation when talking to cisco devices");
which will let you load the module with the option ml_explode = 0 if you
want that property.
Making it runtime per link selectable would be nicer but thats a bit more
work.
Alan
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: Joe Perches @ 2010-03-26 16:33 UTC (permalink / raw)
To: Alan Cox; +Cc: Richard Hartmann, linux-kernel, netdev, linux-ppp
In-Reply-To: <20100326160226.0159ac3b@lxorguk.ukuu.org.uk>
On Fri, 2010-03-26 at 16:02 +0000, Alan Cox wrote:
> > We are fully aware that this code is not nearly up for inclusion into
> > the kernel. What we hope to achieve is that someone with the skills to
> > do this properly will introduce an option to turn off fragmentation on
> > PPP multi-link or to just do away with it completely.
>
> You should be able to manage that I'm sure:
[]
> MODULE_PARM_DESC(ml_expode, "Set this to zero to disabling multilink \
> fragmentation when talking to cisco devices");
trivial:
It's better to use something like:
MODULE_PARM_DESC(ml_expode, "Set this to zero to disable multilink "
"fragmentation when talking to cisco devices");
so odd spacing from the continuation line aren't
used in the description.
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: Richard Hartmann @ 2010-03-26 16:39 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, netdev, linux-ppp
In-Reply-To: <20100326160226.0159ac3b@lxorguk.ukuu.org.uk>
On Fri, Mar 26, 2010 at 17:02, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> You should be able to manage that I'm sure:
Hopefully. We will see :)
> MODULE_PARM_DESC(ml_expode, "Set this to zero to disabling multilink \
> fragmentation when talking to cisco devices");
To be exact, this is not a Linux vs. Cisco issue, but a Linux vs. world
issue.
At least the last-level support of Telefonica and QSC was definite and
adamant about not enabling fragmentation on _any_ PPP multi-link, ever.
Also, I am not sure if it would not be better to default to no
fragmentation and enable it optionally. I am aware that changing default
behaviour is always a bit of a problem but to the best of my knowledge
enabling fragmentation is a bug in any and all real-world applications.
Richard
^ permalink raw reply
* Re: Problem with talking to the kernel and iproute2/ifconfig
From: David Miller @ 2010-03-26 16:42 UTC (permalink / raw)
To: pstaszewski; +Cc: kaber, netdev
In-Reply-To: <4BABA2C9.3090805@itcare.pl>
From: Paweł Staszewski <pstaszewski@itcare.pl>
Date: Thu, 25 Mar 2010 18:52:09 +0100
> This patch resolve this problem and all is working now correctly.
Patrick, since this is now tested to work, please make a formal
submission of this fix if you haven't already.
Thanks!
^ permalink raw reply
* Re: [PATCH] net: ipmr/ip6mr: prevent out-of-bounds vif_table access
From: David Miller @ 2010-03-26 16:51 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <4BAC823F.8050409@dev.6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
Date: Fri, 26 Mar 2010 10:45:35 +0100
> please consider the attached patch about IPv4 and IPv6 multicast.
Already fixed by Patrick McHardy recently:
commit a50436f2cd6e85794f7e1aad795ca8302177b896
Author: Patrick McHardy <kaber@trash.net>
Date: Wed Mar 17 06:04:14 2010 +0000
net: ipmr/ip6mr: fix potential out-of-bounds vif_table access
mfc_parent of cache entries is used to index into the vif_table and is
initialised from mfcctl->mfcc_parent. This can take values of to 2^16-1,
while the vif_table has only MAXVIFS (32) entries. The same problem
affects ip6mr.
Refuse invalid values to fix a potential out-of-bounds access. Unlike
the other validity checks, this is checked in ipmr_mfc_add() instead of
the setsockopt handler since its unused in the delete path and might be
uninitialized.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 8582e12..0b9d03c 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -802,6 +802,9 @@ static int ipmr_mfc_add(struct net *net, struct mfcctl *mfc, int mrtsock)
int line;
struct mfc_cache *uc, *c, **cp;
+ if (mfc->mfcc_parent >= MAXVIFS)
+ return -ENFILE;
+
line = MFC_HASH(mfc->mfcc_mcastgrp.s_addr, mfc->mfcc_origin.s_addr);
for (cp = &net->ipv4.mfc_cache_array[line];
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 52e0f74..23e4ac0 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1113,6 +1113,9 @@ static int ip6mr_mfc_add(struct net *net, struct mf6cctl *mfc, int mrtsock)
unsigned char ttls[MAXMIFS];
int i;
+ if (mfc->mf6cc_parent >= MAXMIFS)
+ return -ENFILE;
+
memset(ttls, 255, MAXMIFS);
for (i = 0; i < MAXMIFS; i++) {
if (IF_ISSET(i, &mfc->mf6cc_ifset))
^ permalink raw reply related
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: Alexander E. Patrakov @ 2010-03-26 17:00 UTC (permalink / raw)
To: Alan Cox; +Cc: Richard Hartmann, linux-kernel, netdev, linux-ppp
In-Reply-To: <20100326160226.0159ac3b@lxorguk.ukuu.org.uk>
26.03.2010 21:02, Alan Cox wrote:
> You can then do this
>
> static int ml_explode = 1;
> module_param(ml_explode, int, 0600);
> MODULE_PARM_DESC(ml_expode, "Set this to zero to disabling multilink \
> fragmentation when talking to cisco devices");
>
> which will let you load the module with the option ml_explode = 0 if you
> want that property.
>
> Making it runtime per link selectable would be nicer but thats a bit more
> work.
Doesn't it work already via echoing values to
/sys/module/ppp/generic/parameters/ml_explode in the above code?
--
Alexander E. Patrakov
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: David Miller @ 2010-03-26 16:59 UTC (permalink / raw)
To: richih.mailinglist; +Cc: alan, linux-kernel, netdev, linux-ppp
In-Reply-To: <v2v2d460de71003260939w4877df7em9e3084a315b0962f@mail.gmail.com>
From: Richard Hartmann <richih.mailinglist@gmail.com>
Date: Fri, 26 Mar 2010 17:39:27 +0100
> At least the last-level support of Telefonica and QSC was definite
> and adamant about not enabling fragmentation on _any_ PPP
> multi-link, ever.
I'm sure we can find just as many counter examples.
I doubt we'll ever be able to change the default here,
sorry.
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: Alan Cox @ 2010-03-26 17:04 UTC (permalink / raw)
To: Alexander E. Patrakov; +Cc: Richard Hartmann, linux-kernel, netdev, linux-ppp
In-Reply-To: <4BACE827.4070006@gmail.com>
On Fri, 26 Mar 2010 22:00:23 +0500
"Alexander E. Patrakov" <patrakov@gmail.com> wrote:
> 26.03.2010 21:02, Alan Cox wrote:
>
> > You can then do this
> >
> > static int ml_explode = 1;
> > module_param(ml_explode, int, 0600);
> > MODULE_PARM_DESC(ml_expode, "Set this to zero to disabling multilink \
> > fragmentation when talking to cisco devices");
> >
> > which will let you load the module with the option ml_explode = 0 if you
> > want that property.
> >
> > Making it runtime per link selectable would be nicer but thats a bit more
> > work.
>
> Doesn't it work already via echoing values to
> /sys/module/ppp/generic/parameters/ml_explode in the above code?
Thats runtime (and why I set 0600 in the permissions for the example) but
not per link.
Alan
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: James Carlson @ 2010-03-26 17:04 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Alan Cox, linux-kernel, netdev, linux-ppp
In-Reply-To: <v2v2d460de71003260939w4877df7em9e3084a315b0962f@mail.gmail.com>
Richard Hartmann wrote:
> Also, I am not sure if it would not be better to default to no
> fragmentation and enable it optionally. I am aware that changing default
> behaviour is always a bit of a problem but to the best of my knowledge
> enabling fragmentation is a bug in any and all real-world applications.
It worked well and was enabled by default on all the Bay Networks
equipment I used ~15 years ago. And I know for certain that we tested
with other gear (Ascend and Clam, probably) that did it right.
If it works with the equipment you're using, it's a useful feature in
that it can balance out the latencies among the links, resulting in much
lower overall latency observed by higher layers -- especially so on
lower-speed links where MP is more likely to be used. Without it,
you're left either waiting for the one slow link choking on a big packet
to catch up, or (worse) disabling the sequence headers altogether,
resulting in reordering unless you're really "clever."
It's a darned shame that lame implementations would force a change in
the default ...
--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: David Miller @ 2010-03-26 17:04 UTC (permalink / raw)
To: richih.mailinglist; +Cc: alan, linux-kernel, netdev, linux-ppp
In-Reply-To: <20100326.095929.04683456.davem@davemloft.net>
BTW, it seems your email client very thoroughly corrupted your
original patch submission.
This is a common problem with gmail, please read:
linux/Documentation/email-clients.txt
so that you can learn how to adjust your email client settings such
that your outgoing patches are usable by us.
Thanks.
^ permalink raw reply
* [PATCH] net: fix netlink address dumping in IPv4/IPv6
From: Patrick McHardy @ 2010-03-26 17:13 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-net-fix-netlink-address-dumping-in-IPv4-IPv6.patch --]
[-- Type: application/mbox, Size: 1420 bytes --]
^ permalink raw reply
* Re: [PATCH] benet: Fix compile warnnings in drivers/net/benet/be_ethtool.c
From: Ajit Khaparde @ 2010-03-26 17:16 UTC (permalink / raw)
To: wzt.wzt; +Cc: linux-kernel, netdev, linux-drivers, sathyap
In-Reply-To: <20100326061259.GB30341@localhost.localdomain>
On 26/03/10 14:12 +0800, wzt.wzt@gmail.com wrote:
> Fix the following warnings:
>
> be_ethtool.c:493: warning: integer constant is too large for 'long' type
> be_ethtool.c:493: warning: integer constant is too large for 'long' type
>
> Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com>
I would suggest using be2net instead of benet during the commit.
be2net: Fix compile warnnings in drivers/net/benet/be_ethtool.c
Acked-by: Ajit Khaparde <ajitk@serverengines.com>
^ permalink raw reply
* Re: [PATCH] net: ipmr/ip6mr: prevent out-of-bounds vif_table access
From: Nicolas Dichtel @ 2010-03-26 17:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100326.095137.165317348.davem@davemloft.net>
yes, but I think that it is not enough, ip[6]mr_mfc_add() is only called via
setsockopt().
When a multicast packet arrived in ip6_mr_input(), if there is no cache
ip6mr_cache_unresolved() will be called and this function will add an entry with
parent == 65535.
And the second problem is that when a vif is removed, no cleanup is made in
cache entry. Hence, we can have a cache entry which points to an invalid vif
(dev is set ot NULL).
Regards,
Nicolas
Le 26.03.2010 17:51, David Miller a écrit :
> From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
> Date: Fri, 26 Mar 2010 10:45:35 +0100
>
>> please consider the attached patch about IPv4 and IPv6 multicast.
>
> Already fixed by Patrick McHardy recently:
>
> commit a50436f2cd6e85794f7e1aad795ca8302177b896
> Author: Patrick McHardy <kaber@trash.net>
> Date: Wed Mar 17 06:04:14 2010 +0000
>
> net: ipmr/ip6mr: fix potential out-of-bounds vif_table access
>
> mfc_parent of cache entries is used to index into the vif_table and is
> initialised from mfcctl->mfcc_parent. This can take values of to 2^16-1,
> while the vif_table has only MAXVIFS (32) entries. The same problem
> affects ip6mr.
>
> Refuse invalid values to fix a potential out-of-bounds access. Unlike
> the other validity checks, this is checked in ipmr_mfc_add() instead of
> the setsockopt handler since its unused in the delete path and might be
> uninitialized.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index 8582e12..0b9d03c 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
> @@ -802,6 +802,9 @@ static int ipmr_mfc_add(struct net *net, struct mfcctl *mfc, int mrtsock)
> int line;
> struct mfc_cache *uc, *c, **cp;
>
> + if (mfc->mfcc_parent >= MAXVIFS)
> + return -ENFILE;
> +
> line = MFC_HASH(mfc->mfcc_mcastgrp.s_addr, mfc->mfcc_origin.s_addr);
>
> for (cp = &net->ipv4.mfc_cache_array[line];
> diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
> index 52e0f74..23e4ac0 100644
> --- a/net/ipv6/ip6mr.c
> +++ b/net/ipv6/ip6mr.c
> @@ -1113,6 +1113,9 @@ static int ip6mr_mfc_add(struct net *net, struct mf6cctl *mfc, int mrtsock)
> unsigned char ttls[MAXMIFS];
> int i;
>
> + if (mfc->mf6cc_parent >= MAXMIFS)
> + return -ENFILE;
> +
> memset(ttls, 255, MAXMIFS);
> for (i = 0; i < MAXMIFS; i++) {
> if (IF_ISSET(i, &mfc->mf6cc_ifset))
^ permalink raw reply
* Re: Does Realtek RTL8110S and RTL8100C work ?
From: Markus Feldmann @ 2010-03-26 17:20 UTC (permalink / raw)
To: netdev
In-Reply-To: <4BABC170.7080008@computer.org>
Thanks for you answer Jan,
do you know the developer e-mail adress?
So 1000Mbit/s is not possible at the moment, but does it work stable?
regards Markus
^ permalink raw reply
* ip6_dst_dev for IPv4
From: Mattias Rönnblom @ 2010-03-26 16:59 UTC (permalink / raw)
To: netdev
Hi,
I'm implemeting per-interface SNMP-style network statistics for IPv4,
just like what already exists in the current kernel for IPv6
(/proc/net/dev_snmp6).
For output packets one needs to determine the output interface, and
the v6 statistics uses the ip6_dst_idev() function (ip6_fib.h). I
can't seem to find a corresponding function for IPv4. Is there?
Would someting like:
struct in_device* out_dev = in_dev_get(skb_dst(skb)->dev);
work?
Best regards,
Mattias
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Christoph Lameter @ 2010-03-26 17:33 UTC (permalink / raw)
To: Andi Kleen; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <20100322185310.GA20695@one.firstfloor.org>
Here is a pgm.7 manpage describing how the socket API could look like for
a PGM implementation.
I dumped the RM_* based socket options from the other OS since most of the
options were unusable.
.\" This man page is Copyright (C) 2010 Christoph Lameter <cl@linux-foundation.org>.
.\" Permission is granted to distribute possibly modified copies
.\" of this page provided the header is included verbatim,
.\" and in case of nontrivial modification author and date
.\" of the modification is added to the header.
.\"
.TH PGM 7 2010-08-01 "Linux" "Linux Programmer's Manual"
.SH NAME
pgm \- Pragmatic General Multicast Protocol Support for IPv4
.SH SYNOPSIS
.B #include <sys/socket.h>
.br
.B #include <netinet/in.h>
.br
.B #include <linux/pgm.h>
.sp
.B pgm_socket = socket(AF_INET, SOCK_RDM, IPPROTO_PGM);
.br
.B pgm_socket = socket(AF_INET, SOCK_RDM, IPPROTO_UDP);
.SH DESCRIPTION
This is an implementation of the Pragmatic General Multicast Protocol
described in RFC\ 3028.
PGM implements a connection oriented, Reliable Datagram Messaging
(thus SOCK_RDM) protocol. Packets are delivered in order even though the
network may
have reordered, duplicated or dropped packets. Receivers may ask for
retransmission of missed packets (NAK). Transmitters do not keep receiver
state so that an individual sender is able to interact with an unlimited
number of receivers.
The recovery mechanism of PGM can limit the scalability of PGM if too
many receivers are NAKing. Therefore measures exist at various layers
to reduce the potential repair volume that a transmitter may have to
deal with.
PGM supports two variants. The first one is the
.B native PGM protocol
which uses its own IP protocol implementation at the same level as TCP and UDP.
Native PGM supports NAK suppression ("assist") by network elements (Cisco,
Juniper and other commercially available routers have support for PGM) which
is an important measure to reduce the NAK volume in case of packet loss during
multicast replication of messages in the network. Routers can consolidate
multiple NAKs from downstream into a single upstream and are also able to
use
.B FEC
(Forward Error Correction) to directly provide repair data without having to
forward NAKs to a transmitter.
The second variant is
.B PGM over UDP.
UDP is used as a transport protocol
instead of IP. PGM over UDP does
.B not
support assist from network elements and
therefore has limited support for NAK suppression. PGM over UDP mainly exists
because of the lack of kernel based PGM implementations. Using raw sockets
for packet creation and packet reception is inefficient and slow. User space
based PGM implementation typically are restricted to a single stream or multiple
stream in the same process since the in kernel multiplexing available for TCP
and UDP does not exist.
PGM over UDP allows the use of UDP port multiplexing instead which allows for]
efficient operation of multiple streams on a single system even if the
OS has no native support for PGM.
Creation of a PGM socket will lead to an unconnected socket. A sender must connect
to a multicast address to be able to send messages. A receiver needs to
bind to the multicast address and port number of interest and then listen
to the socket. The receiver can accept a connection when PGM traffic is
received on the chosen PGM multicast address and port. It is then
possible to receive datagrams on the PGM socket.
When
.BR connect (2)
is called on the socket, the multicast destination address is set and
datagrams can then be sent using
.BR send (2)
or
.BR write (2).
It is not possible to send to other destinations than the single multicast
address connected to. Note that the the send operations will cause the
application to be throttled if the maximum transmission rate is exceeded.
Throttling can be avoided by setting the socket to non blocking mode or
using MSG_DONTWAIT.
In order to receive packets, the socket needs to be bound to a multicast
address first by using
.BR bind (2).
All receive operations return only one packet.
When the packet is smaller than the passed buffer, only that much
data is returned; when it is bigger, the packet is truncated and the
.B MSG_TRUNC
flag is set.
.B MSG_WAITALL
is not supported.
Some IP options may be sent or received using the socket options described in
.BR ip (7).
However, multicast join and leave operations are not supported.
See
.BR ip (7).
By default, Linux PGM does path MTU (Maximum Transmission Unit) discovery.
This means the kernel
will keep track of the MTU to a specific target IP address and return
.B EMSGSIZE
when a PGM packet write exceeds it.
When this happens, the application should decrease the packet size.
Path MTU discovery can be also turned off using the
.B IP_MTU_DISCOVER
socket option or the
.I /proc/sys/net/ipv4/ip_no_pmtu_disc
file; see
.BR ip (7)
for details.
When turned off, PGM will fragment outgoing PGM packets
that exceed the interface MTU.
However, disabling it is not recommended
for performance and reliability reasons.
.SS "Address Format"
PGM supports IPv4 and IPv6 but Linux currently only supports IPv4. The
.I sockaddr_in
address format described in
.BR ip (7)
is used.
.SS "Error Handling"
All fatal errors will be passed to the user as an error return even
when the socket is not connected.
This includes asynchronous errors
received from the network.
You may get an error for an earlier packet
that was sent on the same socket.
When the
.B IP_RECVERR
option is enabled, all errors are stored in the socket error queue,
and can be received by
.BR recvmsg (2)
with the
.B MSG_ERRQUEUE
flag set.
.SS /proc interfaces
System-wide PGM parameter settings can be accessed by files in the directory
.IR /proc/sys/net/ipv4/ .
.TP
.IR pgm_mem " "
This is a vector of three integers governing the number
of pages allowed for queueing by all PGM sockets.
.RS
.TP 10
.I min
Below this number of pages, PGM is not bothered about its
memory appetite.
When the amount of memory allocated by PGM exceeds
this number, PGM starts to moderate memory usage.
.TP
.I pressure
This value was introduced to follow the format of
.IR tcp_mem
(see
.BR tcp (7)).
.TP
.I max
Number of pages allowed for queueing by all PGM sockets.
.RE
.IP
Defaults values for these three items are
calculated at boot time from the amount of available memory.
.TP
.IR pgm_window_size_default " (integer; default value: 10 MB)"
Default size, in bytes, of receive and transmit windows used by PGM sockets.
Each PGM socket is able to use the size for the receiving data window,
even if total pages of PGM sockets exceed pgm_mem pressure.
.TP
.IR pgm_window_msec_default " (integer; default value: 2000)"
Default time for packets to keep in the transmit and receive windows.
Each PGM socket is able to use the time period to resend data,
even if total pages of PGM sockets exceed
.I pgm_mem
pressure.
.TP
.IR pgm_ambient_spm_msecs " (integer; default value 15 seconds)"
Unconditional heartbeat sent by PGM transmitters to periodically notify receivers
about the stream status.
.TP
.IR pgm_spm_list_usec " (integers; default value: 1000 1000 4000 8000 16000 32000 64000 1280000 256000 1000000 2000000 8000000) "
Intervals for successive SPM heatbearts for the case that the connection goes idle. Initial SPMs are rapid to allow for
fast discovery of a missed packet and then back off until the unconditional heartbeat limit is reached.
.TP
.IR pgm_transmitter_rate_kbps "(integer; default value: 56)"
Default limit on the rate of traffic produced by a single transmitter.
The rate is an overall maximum of repair and original data. The limit
is set low because transmitters can do a lot of harm to the network
(especially WAN links) if they sent at high rates. It it advisable to
be careful when increasing the rate.
.TP
.IR pgm_transmitter_repair_rate_kpbs "(integer; default value 30) "
Default limit on the amount of repair data sent by a single transmitter
.TP
.IR pgm_transmitter_nak_ignore_after_rdata_msec "(integer; default 50)"
Period during which to ignore receiver NAKs after repair data was sent
(is usually set to correlate to the maximum WAN delay seen). This is
used to avoid useless additional repair data while NAK / repair data
is in flight.
.TP
.IR pgm_crybaby_rate_kbps " (integer; default 20)"
Maximum rate of repair traffic to a single receiver. A single receiver may
be slow and not able to keep up. Therefore it may continually ask for repairs (Thus
.B crybaby).
This parameter allows to limit the impact that continual repair traffic by the crybaby and
typically causes the crybaby to get so far out of sync that the receiver will finally have
to give up since messages for which repair is needed have been expired on the transmitter side.
Note that the transmitters do not keep track of the receivers. Crybaby detection is an
opportunitic heuristic method.
.TP
.IR pgm_fec_proactive_packets " (integer; default 0 )"
The number of parity packets to insert in each sequence of
.B pgm_fec_group_size
packets. FEC (Forward Error Correction) is another means to reduce NAK
traffic in configurations with a large number of receivers. Receivers
(and network elements) will be able to reconstruct missed packets on their
own without resorting to NAKs. However, if too many packets are missed and
recover is not possible then NAKs will still be sent.
.TP
.IR pgm_fec_group_size " (integer; default 16)"
Defines a unit of packets for which FEC parity packets are created.
.TP
.IR pgm_nak_retries " (integer; default 20)"
The number of recovery attempts to make for a single message before giving up.
.TP
.IR pgm_naks_per_sec " (integer; default 50)"
The maximum number of NAKs to send per second.
.IR pgm_debug " (integer; default 0)"
Allows enabling diagnostics for PGM interaction on the network.
If set to one then PGM will log all recovery activities/
If set to two then PGM will additionally log SPMs and SPMR and connection setup and teardown.
If set to three then PGM will log all activities in the syslog.
.SS "Socket Options"
To set or get a PGM socket option, call
.BR getsockopt (2)
to read or
.BR setsockopt (2)
to write the option with the option level argument set to
.BR IPPROTO_PGM .
.TP
.BR PGM_TRANSMITTER_CONFIG
This option is used to set up parameters for the transmitter before
connecting to a multicast address. The option cannot be used on a
connected SOCK_RDM socket. It is recommended to first get the
configuration data (which will contain the configured OS defaults) and
then modify individual fields as needed.
.sp
.in +4n
.nf
struct pgm_transmitter_config {
int rate_kbyte; /* Maximum rate per second */
int window_msecs; /* Window maximum packet age */
int window_kbytes; /* Window maximum size in kbytes */
int ambient_spm_msecs; /* Unconditional SPM */
int spm_msecs[12]; /* Idle SPM backoff */
int repeat_nak_ignore_msecs; /* How long to skip nacks after sending rdata */
int repair_rate_kbyte; /* Max permitted rate of repair traffic */
int crybaby_rate_kbyte; /* Max rate of repair traffic to individual receiver */
int transmit_only:1; /* If set do not process feedback from receivers */
int fec:1; /* Enable forward error correction */
int fec_parity:1; /* Respond to parity repair packet requests */
int fec_packets_per_group; /* Maximum number of packets for a group. */
int fec_proactive_packets; /* Number of proactive packets per group. */
int fec_group_size; /* Number of packets to be treated as a group. Power of two */
}
.fi
.TP
.BR PGM_TRANSMITTER_STATISTICS
Retrieves transmitter statistics.
.sp
.in +4n
.nf
struct pgm_transmitter_stats {
u64 bytes_received;
u64 data_send;
u64 naks_received;
u64 naks_too_late; /* NAKs received after receive window advanced */
u64 naks_outstanding; /* Number of NAKs awaiting response */
u64 naks_after_rdata; /* Number of NAKs after RDATA sequences were sent which were ignored */
u64 rdata_packets; /* Repair data */
u64 odata_packets; /* Original data */
u32 first_seqid; /* Oldest sequence id in window */
u32 last_seqid; /* Newest sequence id in window */
};
fi
.TP
.BR PGM_RECEIVER_CONFIG
Used to setup receiver parameters before accepting a connection.
The option cannot be used a on a connected SOCK_RDM socket.
.sp
.in +4n
.nf
struct pgm_receiver_config {
int window_msecs; /* Receive window maximum age (per transmitter) */
int window_kbyte; /* Receive window maximum size (per transmitter) */
int nak_retries; /* Nak retries before giving up */
int nak_ncf_retries; /* Nak retries after NCF before giving up */
int nak_backoff_interval; /* time to backoff on NAK failure */
int naks_per_sec; /* Limit on the naks per second */
int peer_timeout; /* Discard peer if silent for this time period */
int spmr_timeout; /* Abort connection if no SPMR response */
int receive_only:1; /* Never send data to sender */
}
.fi
.TP
.BR PGM_RECEIVER_STATISTICS
Retrieves receiver statistics.
.sp
.in +4n
.nf
struct pgm_receiver_stats {
u64 bytes_received; /* Total bytes received */
u64 data_received /* Useful data bytes received */
u64 odata_packets; /* Number of ODATA (original) sequences */
u64 rdata_packets; /* Number of RDATA (repair) sequences */
u64 odata_duplicates; /* Duplicate ODATA */
u64 rdata_duplicates; /* Duplicate RDATA */
u32 first_seqid; /* First buffered sequence id (first transmitter) */
u32 last_seqid; /* Last buffered sequence id (first transmitter) */
u32 first_naked_seqid; /* First sequence id that was naked */
u64 pending_naks; /* Outstanding naks */
u64 pending_ncfs; /* Outstanding ncfs */
u64 naks_sent;
u64 parity_naks_sent;
u32 active_transmitters; /* Number of transmitters */
};
.fi
.SS Ioctls
These ioctls can be accessed using
.BR ioctl (2).
The correct syntax is:
.PP
.RS
.nf
.BI int " value";
.IB error " = ioctl(" pgm_socket ", " ioctl_type ", &" value ");"
.fi
.RE
.TP
.BR FIONREAD " (" SIOCINQ )
Gets a pointer to an integer as argument.
Returns the size of the next pending datagram in the integer in bytes,
or 0 when no datagram is pending.
.TP
.BR TIOCOUTQ " (" SIOCOUTQ )
Returns the number of data bytes in the local send queue.
.PP
In addition all ioctls documented in
.BR ip (7)
and
.BR socket (7)
are supported.
.SH ERRORS
All errors documented for
.BR socket (7)
or
.BR ip (7)
may be returned by a send or receive on a PGM socket.
.TP
.B ECONNREFUSED
The socket was not associated with a multicast address. For a receiver
this may mean that no PGM traffic was detected on the given port. The
address specified may not be a valid multicast address.
.TP
.B NOTCONN
Socket is not connected.
.TP
.B EISCONN
Socket is already connected.
.TP
.B ECONNABORTED
Receiver was not able to keep up. Connection was
torn down.
.\" .SH CREDITS
.\" This man page was written by Christoph Lameter.
.SH "SEE ALSO"
.BR ip (7),
.BR raw (7),
.BR socket (7),
.BR udp (7)
RFC\ 3028 for the Pragmatic General Multicast protocol.
.br
RFC\ 1122 for the host requirements.
.br
RFC\ 1191 for a description of path MTU discovery.
.SH COLOPHON
This page is part of release 3.xx of the Linux
.I man-pages
project.
A description of the project,
and information about reporting bugs,
can be found at
http://www.kernel.org/doc/man-pages/.
^ permalink raw reply
* Re: UDP path MTU discovery
From: Rick Jones @ 2010-03-26 17:48 UTC (permalink / raw)
To: David Miller; +Cc: gdt, netdev
In-Reply-To: <20100325.202636.149498207.davem@davemloft.net>
David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Thu, 25 Mar 2010 17:53:11 -0700
>
>
>>So, presuming it is indeed a bug what form might a fix take? Are you
>>suggesting there should be a way for an application to say "Please let
>>me see/know about the ICMP messages?" Is that option available on
>>other platforms as a platform-specific extension?
>
>
> We already provide this information.
>
> The socket ends up with EMSGSIZE in it's error queue, so the next time
> the application does I/O it sees that error immediately from the
> read/write call and thus knows that path MTU arrived.
A possibly pedantic question, but only when it does I/O, or also when/if it is
in poll/select?
What distinguishes this EMSGSIZE from a run-of-the-mill EMSGSIZE error such as
one gets from trying to send a datagram larger than SO_SNDBUF?
That is something that happens all the time in netperf when people forget a -m
option on UDP_STREAM tests :) Netperf gets the error and exits. But supposing
I wanted to make netperf more sophisticated in that regard - what sort of things
must it do? Call getsockopt(SO_SNDBUF) to check the size of the failed send
against SO_SNDBUF and only then decide if it is an error on this send or an ICMP
Datagram Too Big arrived indication from a previous send? I know that netperf
already has this information, so using it as the example is a bit stretched, but
lets presume for the moment that netperf just has a socket handed to it from
"somewhere."
rick jones
^ permalink raw reply
* Re: [PATCH] net: ipmr/ip6mr: prevent out-of-bounds vif_table access
From: David Miller @ 2010-03-26 18:11 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <4BACECA6.2050506@dev.6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
Date: Fri, 26 Mar 2010 18:19:34 +0100
> yes, but I think that it is not enough, ip[6]mr_mfc_add() is only
> called via setsockopt().
>
> When a multicast packet arrived in ip6_mr_input(), if there is no
> cache ip6mr_cache_unresolved() will be called and this function will
> add an entry with parent == 65535.
>
> And the second problem is that when a vif is removed, no cleanup is
> made in cache entry. Hence, we can have a cache entry which points to
> an invalid vif (dev is set ot NULL).
Ok, I'll take another look at your patch, thanks for
explaining.
^ permalink raw reply
* Re: [alsa-devel] [PATCH 13/27] drivers/net/of: don't use deprecated field in of_platform_driver
From: Grant Likely @ 2010-03-26 18:23 UTC (permalink / raw)
To: Timur Tabi
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <ed82fe3e1003260823q5a2ba774ifd3465b41b8f0a10-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Mar 26, 2010 at 9:23 AM, Timur Tabi <timur.tabi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I'm seeing this error with this patch applied, when building for an mpc8641_hpcn
>
> CC drivers/net/gianfar.o
> drivers/net/gianfar.c: In function 'gfar_of_init':
> drivers/net/gianfar.c:606: error: 'struct platform_device' has no
> member named 'node'
> drivers/net/gianfar.c:644: error: 'struct platform_device' has no
> member named 'node'
> drivers/net/gianfar.c: In function 'gfar_probe':
> drivers/net/gianfar.c:891: error: 'struct platform_device' has no
> member named 'node'
> make[2]: *** [drivers/net/gianfar.o] Error 1
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
Thanks for the testing Timur. I missed converting that driver. I
believe I've got that fixed now and I'll be pushing out a new tree
real-soon-now.
g.
^ permalink raw reply
* [PATCH net-next-2.6] sctp: Use ipv6_addr_diff() in sctp_v6_addr_match_len().
From: YOSHIFUJI Hideaki @ 2010-03-26 18:34 UTC (permalink / raw)
To: davem; +Cc: yoshfuji, netdev
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
net/sctp/ipv6.c | 15 +--------------
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index 240dceb..216d88f 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -276,20 +276,7 @@ static struct dst_entry *sctp_v6_get_dst(struct sctp_association *asoc,
static inline int sctp_v6_addr_match_len(union sctp_addr *s1,
union sctp_addr *s2)
{
- struct in6_addr *a1 = &s1->v6.sin6_addr;
- struct in6_addr *a2 = &s2->v6.sin6_addr;
- int i, j;
-
- for (i = 0; i < 4 ; i++) {
- __be32 a1xora2;
-
- a1xora2 = a1->s6_addr32[i] ^ a2->s6_addr32[i];
-
- if ((j = fls(ntohl(a1xora2))))
- return (i * 32 + 32 - j);
- }
-
- return (i*32);
+ return ipv6_addr_diff(&s1->v6.sin6_addr, &s2->v6.sin6_addr);
}
/* Fills in the source address(saddr) based on the destination address(daddr)
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCHv2 0/4]netxen: bug fixes
From: David Miller @ 2010-03-26 18:51 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <1269599410-17809-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Fri, 26 Mar 2010 03:30:06 -0700
> David,
> Series of 4 patches to fix bugs.
> These are v2 patches, fixing ioremap issue reported by you.
> Apply them on net-2.6 branch.
All applied, thanks.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/3] ixgbevf: Fix signed/unsigned int error
From: David Miller @ 2010-03-26 18:56 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, gregory.v.rose
In-Reply-To: <20100324193515.6078.27035.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 24 Mar 2010 12:35:42 -0700
> From: Greg Rose <gregory.v.rose@intel.com>
>
> In the Tx mapping function if a DMA error occurred then the unwind of
> previously mapped sections would improperly check an unsigned int if
> it was less than zero. Changed the index variable to signed to avoid
> the error.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/3] ixgbe: In SR-IOV mode insert delay before bring the adapter up
From: David Miller @ 2010-03-26 18:57 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, gregory.v.rose
In-Reply-To: <20100324193608.6078.61157.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 24 Mar 2010 12:36:08 -0700
> From: Greg Rose <gregory.v.rose@intel.com>
>
> VFs running in guest VMs do not respond in as timely a manner to
> PF indication it is going down as they do when running in the host
> domain. If the adapter is in SR-IOV mode insert a two second delay
> to guarantee that all VFs have had time to respond to the PF reset.
> In any case resetting the PF while VFs are active should be
> discouraged but if it must be done then there will be a two
> second delay to help synchronize resets among the PF and all the
> VFs.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, but...
I know why you might need to do this, but this is going to completely
explode if someone tries to, f.e. bring up thousands of these
interfaces.
Maybe that's not practical, but is, say, 30? With a 2 second delay
each that's a full minute hanging at the command line or the bootup
scripts.
My point is that this behavior is basically extremely undesirable.
^ permalink raw reply
* Re: [net-2.6 PATCH 3/3] ixgbe: Change where clear_to_send_flag is reset to zero.
From: David Miller @ 2010-03-26 18:58 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, gregory.v.rose
In-Reply-To: <20100324193626.6078.32074.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 24 Mar 2010 12:36:27 -0700
> From: Greg Rose <gregory.v.rose@intel.com>
>
> The clear_to_send flag is being cleared before the call to ping all
> the VFs. It should be called after pinging all the VFs.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH] ixgbe: cleanup maximum number of tx queues
From: David Miller @ 2010-03-26 18:58 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, john.r.fastabend
In-Reply-To: <20100324200144.6384.17291.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 24 Mar 2010 13:01:45 -0700
> From: John Fastabend <john.r.fastabend@intel.com>
>
> In the last patch I missed an unecessary min_t comparison.
> This patch removes it, the path allocates at most
> 72 tx queues for 82599 and 24 for 82598 there is no need
> for this check.
>
> Additionally this sets MAX_[TX|RX]_QUEUES to 72. Which is
> used as the size for the tx/rx_ring arrays. There is no
> reason to have more tx_rings/rx_rings then num_tx_queues.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ 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