* 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
* Re: [net-2.6 PATCH] ixgbe: Don't allow user buffer count to exceed 256
From: David Miller @ 2010-03-26 18:58 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, robert.w.love, yi.zou, frank_1.zhang
In-Reply-To: <20100324200204.6384.63977.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 24 Mar 2010 13:02:04 -0700
> From: Robert Love <robert.w.love@intel.com>
>
> If the user buffer count was 256 the shift would place a 1
> in the offset region leading to errors. It also overwrites
> the uers buffer list. This patch makes sure that at most
> 256 user buffers are allowed for DDP and the buffer count
> is masked properly such that it doesn't overwrite the offset
> when shifting the bits.
>
> Signed-off-by: Robert Love <robert.w.love@intel.com>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Frank Zhang <frank_1.zhang@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/2] ixgbe: Priority tag FIP frames
From: David Miller @ 2010-03-26 18:58 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, robert.w.love, christopher.leech
In-Reply-To: <20100324224500.6653.28216.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 24 Mar 2010 15:45:00 -0700
> From: Robert Love <robert.w.love@intel.com>
>
> Currently FIP (FCoE Initialization Protocol) frames
> are going untagged. This causes various problems
> with FCFs (switches) that have negotiated a priority
> over dcbx. This patch tags FIP frames with the same
> priority as the FCoE frames.
>
> Signed-off-by: Robert Love <robert.w.love@intel.com>
> Signed-off-by: Chris Leech <christopher.leech@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/2] ixgbe: filter FIP frames into the FCoE offload queues
From: David Miller @ 2010-03-26 18:58 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, christopher.leech
In-Reply-To: <20100324224521.6653.17418.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 24 Mar 2010 15:45:21 -0700
> From: Chris Leech <christopher.leech@intel.com>
>
> During FCF solicitation, the switch is supposed to pad the
> solicited advertisement out to the endpoints specified
> maximum FCoE frame size. That means that we need to receive
> FIP frames that are larger than the standard MTU. To make
> sure the receive queue is configured correctly, we should be
> filtering FIP traffic into the FCoE queues.
>
> Signed-off-by: Chris Leech <christopher.leech@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: Rose, Gregory V @ 2010-03-26 19:45 UTC (permalink / raw)
To: David Miller, Kirsher, Jeffrey T; +Cc: netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <20100326.115753.160228163.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Friday, March 26, 2010 11:58 AM
>To: Kirsher, Jeffrey T
>Cc: netdev@vger.kernel.org; gospo@redhat.com; Rose, Gregory V
>Subject: Re: [net-2.6 PATCH 2/3] ixgbe: In SR-IOV mode insert delay
>before bring the adapter up
>
>
>
> My point is that this behavior is basically extremely undesirable.
No argument from me there. We've been discussing design changes to maintain a little more state in the driver so that we wouldn't have to reset the entire device every time someone makes a minor configuration change. However, I have no target date for that. I agree that at some point in systems with a large number of interfaces this behavior becomes untenable.
- Greg
^ permalink raw reply
* Re: [PATCH] r8169: Fix rtl8169_rx_interrupt()
From: François Romieu @ 2010-03-26 20:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sergey Senozhatsky, Oleg Nesterov, David Miller, netdev
In-Reply-To: <1269523180.3626.25.camel@edumazet-laptop>
Eric Dumazet <eric.dumazet@gmail.com> :
[...]
> Thanks for the report. Problem is I am not confident enough on this
> driver.
Your patch is simple and it improves things.
> I believe François Romieu is the one that can possibly push a patch ?
Feel free to push.
--
Ueimor
^ permalink raw reply
* [net-2.6 PATCH] e1000: do not modify tx_queue_len on link speed change
From: Jeff Kirsher @ 2010-03-26 21:25 UTC (permalink / raw)
To: davem
Cc: netdev, gospo, Franco Fichtner, Emil Tantilov, Jesse Brandeburg,
Jeff Kirsher
From: Emil Tantilov <emil.s.tantilov@intel.com>
Previously the driver tweaked txqueuelen to avoid false Tx hang reports
seen at half duplex. This had the effect of overriding user set values
on link change/reset. Testing shows that adjusting only the timeout
factor is sufficient to prevent Tx hang reports at half duplex.
This patch removes all instances of tx_queue_len in the driver.
Based on e1000e patch by Franco Fichtner <franco@lastsummer.de>
CC: Franco Fichtner <franco@lastsummer.de>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000/e1000.h | 1 -
drivers/net/e1000/e1000_main.c | 9 +--------
2 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index 9902b33..2f29c21 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -261,7 +261,6 @@ struct e1000_adapter {
/* TX */
struct e1000_tx_ring *tx_ring; /* One per active queue */
unsigned int restart_queue;
- unsigned long tx_queue_len;
u32 txd_cmd;
u32 tx_int_delay;
u32 tx_abs_int_delay;
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 8be6fae..b15ece2 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -383,8 +383,6 @@ static void e1000_configure(struct e1000_adapter *adapter)
adapter->alloc_rx_buf(adapter, ring,
E1000_DESC_UNUSED(ring));
}
-
- adapter->tx_queue_len = netdev->tx_queue_len;
}
int e1000_up(struct e1000_adapter *adapter)
@@ -503,7 +501,6 @@ void e1000_down(struct e1000_adapter *adapter)
del_timer_sync(&adapter->watchdog_timer);
del_timer_sync(&adapter->phy_info_timer);
- netdev->tx_queue_len = adapter->tx_queue_len;
adapter->link_speed = 0;
adapter->link_duplex = 0;
netif_carrier_off(netdev);
@@ -2316,19 +2313,15 @@ static void e1000_watchdog(unsigned long data)
E1000_CTRL_RFCE) ? "RX" : ((ctrl &
E1000_CTRL_TFCE) ? "TX" : "None" )));
- /* tweak tx_queue_len according to speed/duplex
- * and adjust the timeout factor */
- netdev->tx_queue_len = adapter->tx_queue_len;
+ /* adjust timeout factor according to speed/duplex */
adapter->tx_timeout_factor = 1;
switch (adapter->link_speed) {
case SPEED_10:
txb2b = false;
- netdev->tx_queue_len = 10;
adapter->tx_timeout_factor = 16;
break;
case SPEED_100:
txb2b = false;
- netdev->tx_queue_len = 100;
/* maybe add some timeout factor ? */
break;
}
^ permalink raw reply related
* [net-next-2.6 PATCH] igb: add per-packet timestamping
From: Jeff Kirsher @ 2010-03-26 21:36 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Nicholas Nunley, Jeff Kirsher
From: Nick Nunley <nicholasx.d.nunley@intel.com>
This patch adds support for per-packet timestamping for the
82580 adapter. The rx timestamp code is also pulled out of the
inlined rx hotpath and instead moved to a seperate function.
This version adds a comment explaining the per-packet timestamping
code added to igb_hwtstamp_ioctl().
Signed-off-by: Nicholas Nunley <nicholasx.d.nunley@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/igb/e1000_82575.h | 2 ++
drivers/net/igb/igb.h | 2 ++
drivers/net/igb/igb_main.c | 45 ++++++++++++++++++++++++++++++++++-------
3 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/net/igb/e1000_82575.h b/drivers/net/igb/e1000_82575.h
index c1cad8a..cbd1e12 100644
--- a/drivers/net/igb/e1000_82575.h
+++ b/drivers/net/igb/e1000_82575.h
@@ -53,6 +53,7 @@ extern void igb_rx_fifo_flush_82575(struct e1000_hw *hw);
#define E1000_SRRCTL_DESCTYPE_ADV_ONEBUF 0x02000000
#define E1000_SRRCTL_DESCTYPE_HDR_SPLIT_ALWAYS 0x0A000000
#define E1000_SRRCTL_DROP_EN 0x80000000
+#define E1000_SRRCTL_TIMESTAMP 0x40000000
#define E1000_MRQC_ENABLE_RSS_4Q 0x00000002
#define E1000_MRQC_ENABLE_VMDQ 0x00000003
@@ -109,6 +110,7 @@ union e1000_adv_rx_desc {
#define E1000_RXDADV_HDRBUFLEN_MASK 0x7FE0
#define E1000_RXDADV_HDRBUFLEN_SHIFT 5
#define E1000_RXDADV_STAT_TS 0x10000 /* Pkt was time stamped */
+#define E1000_RXDADV_STAT_TSIP 0x08000 /* timestamp in packet */
/* Transmit Descriptor - Advanced */
union e1000_adv_tx_desc {
diff --git a/drivers/net/igb/igb.h b/drivers/net/igb/igb.h
index a177570..4f69b6d 100644
--- a/drivers/net/igb/igb.h
+++ b/drivers/net/igb/igb.h
@@ -107,6 +107,7 @@ struct vf_data_storage {
#define MAXIMUM_ETHERNET_VLAN_SIZE 1522
/* Supported Rx Buffer Sizes */
+#define IGB_RXBUFFER_64 64 /* Used for packet split */
#define IGB_RXBUFFER_128 128 /* Used for packet split */
#define IGB_RXBUFFER_1024 1024
#define IGB_RXBUFFER_2048 2048
@@ -324,6 +325,7 @@ struct igb_adapter {
#define IGB_82576_TSYNC_SHIFT 19
#define IGB_82580_TSYNC_SHIFT 24
+#define IGB_TS_HDR_LEN 16
enum e1000_state_t {
__IGB_TESTING,
__IGB_RESETTING,
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 2501c5d..9f9382b 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -2602,6 +2602,8 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
E1000_SRRCTL_BSIZEPKT_SHIFT;
srrctl |= E1000_SRRCTL_DESCTYPE_ADV_ONEBUF;
}
+ if (hw->mac.type == e1000_82580)
+ srrctl |= E1000_SRRCTL_TIMESTAMP;
/* Only set Drop Enable if we are supporting multiple queues */
if (adapter->vfs_allocated_count || adapter->num_rx_queues > 1)
srrctl |= E1000_SRRCTL_DROP_EN;
@@ -3936,6 +3938,9 @@ static int igb_change_mtu(struct net_device *netdev, int new_mtu)
* i.e. RXBUFFER_2048 --> size-4096 slab
*/
+ if (adapter->hw.mac.type == e1000_82580)
+ max_frame += IGB_TS_HDR_LEN;
+
if (max_frame <= IGB_RXBUFFER_1024)
rx_buffer_len = IGB_RXBUFFER_1024;
else if (max_frame <= MAXIMUM_ETHERNET_VLAN_SIZE)
@@ -3943,6 +3948,14 @@ static int igb_change_mtu(struct net_device *netdev, int new_mtu)
else
rx_buffer_len = IGB_RXBUFFER_128;
+ if ((max_frame == ETH_FRAME_LEN + ETH_FCS_LEN + IGB_TS_HDR_LEN) ||
+ (max_frame == MAXIMUM_ETHERNET_VLAN_SIZE + IGB_TS_HDR_LEN))
+ rx_buffer_len = MAXIMUM_ETHERNET_VLAN_SIZE + IGB_TS_HDR_LEN;
+
+ if ((adapter->hw.mac.type == e1000_82580) &&
+ (rx_buffer_len == IGB_RXBUFFER_128))
+ rx_buffer_len += IGB_RXBUFFER_64;
+
if (netif_running(netdev))
igb_down(adapter);
@@ -5159,7 +5172,7 @@ static inline void igb_rx_checksum_adv(struct igb_ring *ring,
dev_dbg(&ring->pdev->dev, "cksum success: bits %08X\n", status_err);
}
-static inline void igb_rx_hwtstamp(struct igb_q_vector *q_vector, u32 staterr,
+static void igb_rx_hwtstamp(struct igb_q_vector *q_vector, u32 staterr,
struct sk_buff *skb)
{
struct igb_adapter *adapter = q_vector->adapter;
@@ -5177,13 +5190,18 @@ static inline void igb_rx_hwtstamp(struct igb_q_vector *q_vector, u32 staterr,
* If nothing went wrong, then it should have a skb_shared_tx that we
* can turn into a skb_shared_hwtstamps.
*/
- if (likely(!(staterr & E1000_RXDADV_STAT_TS)))
- return;
- if (!(rd32(E1000_TSYNCRXCTL) & E1000_TSYNCRXCTL_VALID))
- return;
+ if (staterr & E1000_RXDADV_STAT_TSIP) {
+ u32 *stamp = (u32 *)skb->data;
+ regval = le32_to_cpu(*(stamp + 2));
+ regval |= (u64)le32_to_cpu(*(stamp + 3)) << 32;
+ skb_pull(skb, IGB_TS_HDR_LEN);
+ } else {
+ if(!(rd32(E1000_TSYNCRXCTL) & E1000_TSYNCRXCTL_VALID))
+ return;
- regval = rd32(E1000_RXSTMPL);
- regval |= (u64)rd32(E1000_RXSTMPH) << 32;
+ regval = rd32(E1000_RXSTMPL);
+ regval |= (u64)rd32(E1000_RXSTMPH) << 32;
+ }
igb_systim_to_hwtstamp(adapter, skb_hwtstamps(skb), regval);
}
@@ -5291,7 +5309,8 @@ send_up:
goto next_desc;
}
- igb_rx_hwtstamp(q_vector, staterr, skb);
+ if (staterr & (E1000_RXDADV_STAT_TSIP | E1000_RXDADV_STAT_TS))
+ igb_rx_hwtstamp(q_vector, staterr, skb);
total_bytes += skb->len;
total_packets++;
@@ -5571,6 +5590,16 @@ static int igb_hwtstamp_ioctl(struct net_device *netdev,
return 0;
}
+ /*
+ * Per-packet timestamping only works if all packets are
+ * timestamped, so enable timestamping in all packets as
+ * long as one rx filter was configured.
+ */
+ if ((hw->mac.type == e1000_82580) && tsync_rx_ctl) {
+ tsync_rx_ctl = E1000_TSYNCRXCTL_ENABLED;
+ tsync_rx_ctl |= E1000_TSYNCRXCTL_TYPE_ALL;
+ }
+
/* enable/disable TX */
regval = rd32(E1000_TSYNCTXCTL);
regval &= ~E1000_TSYNCTXCTL_ENABLED;
^ permalink raw reply related
* ICMP echo reply fails
From: Andy Fleming @ 2010-03-26 21:48 UTC (permalink / raw)
To: netdev
For various reasons, we have been running a stress test on one of our
boards. The test consists of initiating 2-3 flood pings from a
Windows box running Cygwin, plus one additional ping we use as a
"heartbeat". The ping flood is overwhelming our board (we're dropping
packets at a prodigious rate), but the board continues to respond for
a while. In addition, we are running a script on the board which
alternates bringing up and bringing down the interface every ten
seconds. After a highly variable amount of time, the board stops
replying to the pings. We suspected a driver issue, however, on
closer inspection, we are still able to send and receive packets (I
can ping *from* the board to the PC, and I can *telnet* from the PC to
the board). We tried pinging the board from another PC, and it also
failed. Essentially, ICMP echo requests are being ignored (A glance
at memory indicates that packets are arriving, but no packets are
being enqueued to the ethernet controller). We still have a lot more
debugging to do, but I was wondering if anyone had ever seen something
like this, or might be quicker to realize the obvious mistake we're
making.
Thanks,
Andy Fleming
^ permalink raw reply
* Re: ICMP echo reply fails
From: Eric Dumazet @ 2010-03-26 22:06 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev
In-Reply-To: <2acbd3e41003261448q26cb19d4w63487894b24f0254@mail.gmail.com>
Le vendredi 26 mars 2010 à 16:48 -0500, Andy Fleming a écrit :
> For various reasons, we have been running a stress test on one of our
> boards. The test consists of initiating 2-3 flood pings from a
> Windows box running Cygwin, plus one additional ping we use as a
> "heartbeat". The ping flood is overwhelming our board (we're dropping
> packets at a prodigious rate), but the board continues to respond for
> a while. In addition, we are running a script on the board which
> alternates bringing up and bringing down the interface every ten
> seconds. After a highly variable amount of time, the board stops
> replying to the pings. We suspected a driver issue, however, on
> closer inspection, we are still able to send and receive packets (I
> can ping *from* the board to the PC, and I can *telnet* from the PC to
> the board). We tried pinging the board from another PC, and it also
> failed. Essentially, ICMP echo requests are being ignored (A glance
> at memory indicates that packets are arriving, but no packets are
> being enqueued to the ethernet controller). We still have a lot more
> debugging to do, but I was wondering if anyone had ever seen something
> like this, or might be quicker to realize the obvious mistake we're
> making.
>
> Thanks,
> Andy Fleming
kernel version ?
NIC driver ?
Are ICMP echo request received ? (grep Icmp /proc/net/snmp)
^ permalink raw reply
* [PATCH] Add MSG_WAITFORONE flag to recvmmsg
From: Brandon L Black @ 2010-03-26 22:35 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Arnaldo Carvalho de Melo, Ulrich Drepper,
linux-kernel
From: Brandon L Black <blblack@gmail.com>
Add new flag MSG_WAITFORONE for the recvmmsg() syscall.
When this flag is specified for a blocking socket, recvmmsg()
will only block until at least 1 packet is available. The
default behavior is to block until all vlen packets are
available. This flag has no effect on non-blocking sockets
or when used in combination with MSG_DONTWAIT.
Signed-off-by: Brandon L Black <blblack@gmail.com>
---
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 7b3aae2..354cc56 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -255,6 +255,7 @@ struct ucred {
#define MSG_ERRQUEUE 0x2000 /* Fetch message from error queue */
#define MSG_NOSIGNAL 0x4000 /* Do not generate SIGPIPE */
#define MSG_MORE 0x8000 /* Sender will send more */
+#define MSG_WAITFORONE 0x10000 /* recvmmsg(): block until 1+ packets avail */
#define MSG_EOF MSG_FIN
diff --git a/net/socket.c b/net/socket.c
index 769c386..33304d1 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2133,7 +2133,10 @@ int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int vlen,
if (err)
break;
- ++datagrams;
+
+ /* MSG_WAITFORONE turns on MSG_DONTWAIT after one packet */
+ if (!datagrams++ && (flags & MSG_WAITFORONE))
+ flags |= MSG_DONTWAIT;
if (timeout) {
ktime_get_ts(timeout);
^ permalink raw reply related
* Re: [PATCH] Add MSG_WAITFORONE flag to recvmmsg
From: Eric Dumazet @ 2010-03-26 22:44 UTC (permalink / raw)
To: Brandon L Black
Cc: netdev, David S. Miller, Arnaldo Carvalho de Melo, Ulrich Drepper,
linux-kernel
In-Reply-To: <20100326223530.GA11817@xpc.home>
Le vendredi 26 mars 2010 à 17:35 -0500, Brandon L Black a écrit :
> From: Brandon L Black <blblack@gmail.com>
>
> Add new flag MSG_WAITFORONE for the recvmmsg() syscall.
> When this flag is specified for a blocking socket, recvmmsg()
> will only block until at least 1 packet is available. The
> default behavior is to block until all vlen packets are
> available. This flag has no effect on non-blocking sockets
> or when used in combination with MSG_DONTWAIT.
>
> Signed-off-by: Brandon L Black <blblack@gmail.com>
>
> ---
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index 7b3aae2..354cc56 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -255,6 +255,7 @@ struct ucred {
> #define MSG_ERRQUEUE 0x2000 /* Fetch message from error queue */
> #define MSG_NOSIGNAL 0x4000 /* Do not generate SIGPIPE */
> #define MSG_MORE 0x8000 /* Sender will send more */
> +#define MSG_WAITFORONE 0x10000 /* recvmmsg(): block until 1+ packets avail */
>
> #define MSG_EOF MSG_FIN
>
> diff --git a/net/socket.c b/net/socket.c
> index 769c386..33304d1 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -2133,7 +2133,10 @@ int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int vlen,
>
> if (err)
> break;
> - ++datagrams;
> +
> + /* MSG_WAITFORONE turns on MSG_DONTWAIT after one packet */
> + if (!datagrams++ && (flags & MSG_WAITFORONE))
> + flags |= MSG_DONTWAIT;
Hmmm, no need to test !datagram, just do :
++datagrams;
if (flags & MSG_WAITFORONE)
flags |= MSG_DONTWAIT;
^ permalink raw reply
* Re: ICMP echo reply fails
From: Eric Dumazet @ 2010-03-26 22:46 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev
In-Reply-To: <1269641190.2256.1.camel@edumazet-laptop>
Le vendredi 26 mars 2010 à 23:06 +0100, Eric Dumazet a écrit :
> Le vendredi 26 mars 2010 à 16:48 -0500, Andy Fleming a écrit :
> > For various reasons, we have been running a stress test on one of our
> > boards. The test consists of initiating 2-3 flood pings from a
> > Windows box running Cygwin, plus one additional ping we use as a
> > "heartbeat". The ping flood is overwhelming our board (we're dropping
> > packets at a prodigious rate), but the board continues to respond for
> > a while. In addition, we are running a script on the board which
> > alternates bringing up and bringing down the interface every ten
> > seconds. After a highly variable amount of time, the board stops
> > replying to the pings. We suspected a driver issue, however, on
> > closer inspection, we are still able to send and receive packets (I
> > can ping *from* the board to the PC, and I can *telnet* from the PC to
> > the board). We tried pinging the board from another PC, and it also
> > failed. Essentially, ICMP echo requests are being ignored (A glance
> > at memory indicates that packets are arriving, but no packets are
> > being enqueued to the ethernet controller). We still have a lot more
> > debugging to do, but I was wondering if anyone had ever seen something
> > like this, or might be quicker to realize the obvious mistake we're
> > making.
> >
> > Thanks,
> > Andy Fleming
>
>
> kernel version ?
>
> NIC driver ?
>
> Are ICMP echo request received ? (grep Icmp /proc/net/snmp)
>
vi +1166 net/ipv4/icmp.c
/* Enough space for 2 64K ICMP packets, including
* sk_buff struct overhead.
*/
sk->sk_sndbuf =
(2 * ((64 * 1024) + sizeof(struct sk_buff)));
If many ICMP replies are lost/leaked by your driver when doing up/down
things, ICMP socket can consume all its sndbuf reserve and no more icmp
replies can be sent (a reboot is needed)
You could try changing sk->sk_sndbuf to 0x7FFFFFFF to see if the icmp
replies survive longer to your tests. If this is the case, then find the
leaks in your driver (tx path, maybe you forgot to free skbs in some
reset cases ?)
We should add a SNMP counter for failed ip_append() calls in
icmp_push_reply()...
^ permalink raw reply
* Re: [PATCH] Add MSG_WAITFORONE flag to recvmmsg
From: Brandon Black @ 2010-03-26 22:55 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, David S. Miller, Arnaldo Carvalho de Melo, Ulrich Drepper,
linux-kernel
In-Reply-To: <1269643470.2256.17.camel@edumazet-laptop>
On Fri, Mar 26, 2010 at 5:44 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Hmmm, no need to test !datagram, just do :
>
> ++datagrams;
>
> if (flags & MSG_WAITFORONE)
> flags |= MSG_DONTWAIT;
>
Ok. I've never been through this process before. Do I resubmit a new
subject/thread with the changed patch and [PATCH v2] at this point?
Any other nits about how the patch was sent before I do?
Thanks,
-- Brandon
^ 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