* Re: [REGRESSION,BISECTED] MIPv6 support broken by f4f914b58019f0
From: Arnaud Ebalard @ 2010-05-28 21:15 UTC (permalink / raw)
To: YOSHIFUJI Hideaki
Cc: Brian Haley, David Miller, Jiri Olsa, Scott Otto, netdev
In-Reply-To: <4C000E37.7080306@linux-ipv6.org>
Hi,
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> writes:
>>> I guess I always believed setting SO_BINDTODEVICE should always force
>>> traffic out that interface, but from Yoshifuji's email it seems that
>>> maybe wasn't the intention, at least for things that don't meet
>>> the rt_need_strict() criteria like globals. I don't know the history
>>> behind the setsockopt.
>>
>> The behavior I would expect from a combination of RFC 4191 and
>> SO_BINDTODEVICE sockopt would be the use of the interface as outgoing
>> interface and then the use of the best router (using router preference
>> info, reachability, ...) available on the subnet. IIRC, the router
>> preference info is per default router list in the RFC, i.e. per
>> interface.
>
> Good point.
>
> Whatever our original intention/thought was,
> current RFC says that we should honor outgoing interface
> specified by user (by IPV6_PKTINFO etc.), as we do for
> SO_BINDTODEVICE in IPv4 as well.
>
> In this sense, checking sk->sk_bound_dev_if in
> ip6_route_output() is not enough because we need to
> take outgoing interface specified in ancillary data
> into account, which is set to fl->oif.
>
> How about adding additional "flags" parameter
> for ip6_route_output()?
I think this may provide a better long term solution but getting all
combinations of cases (SO_BINDTODEVICE and other IPv6 sockopts) work
together (possibly with external info like RFC 4191 ones gathered from
RA or specific local routing config) will be a bit tricky.
Meanwhile, regarding the regression, as Brian's fix handles most
cases, I think it would be useful to apply it and push it to the
stable team.
Cheers,
a+
^ permalink raw reply
* Re: Choppy TCP send performance
From: Eric Dumazet @ 2010-05-28 21:16 UTC (permalink / raw)
To: Ivan Novick; +Cc: netdev, Tim Heath
In-Reply-To: <AANLkTilSrX5PifVHlxMjTK-wo_viD8IS_1m1k-vPOlE3@mail.gmail.com>
Le vendredi 28 mai 2010 à 13:38 -0700, Ivan Novick a écrit :
> Hello,
>
> I am using RHEL5 and have 1 Gigabit NIC cards.
>
> When doing a loop sending 128 KB blocks of data using TCP. I am using
> system tap to debug the performance and finding that:
>
> 90% of the send calls take about 100 micro seconds and 10% of the send
> calls take about 10 miliseconds. The average send time is about 1
> milisecond
>
> The 10% of the calls taking about 10 milliseconds seem to be
> correlated with "sk_stream_wait_memory" calls in the kernel.
>
> sk_stream_wait_memory seems to be called when the send buffer is full
> and the next send call does not complete until the send buffer
> utilization goes down from 4,194,304 bytes to 2,814,968 bytes.
>
> This implies that the send that blocks on a full send buffer will not
> complete until there is 1 meg of free space in the send buffer even
> though the send could be accepted into the OS with only 128KB of free
> space.
>
> Do you think I am misinterpreting this data or is there a way to even
> out the send calls so that they they are more even in duration: approx
> 1 milisecond per call. Is there a parameter to reduce how much space
> needs to be free in the send buffer before a blocking send call can
> complete from user space?
static void sock_def_write_space(struct sock *sk)
{
...
if ((atomic_read(&sk->sk_wmem_alloc) << 1) <= sk->sk_sndbuf) {
...
Quick answer is : No, this is not tunable ( independantly than SNDBUF )
SO_SNDLOWAT is not implemented on linux, yet (its value is : 1).
Why would you want to wakeup your thread more than necessary ?
^ permalink raw reply
* Re: Choppy TCP send performance
From: Ivan Novick @ 2010-05-28 21:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Tim Heath
In-Reply-To: <1275081377.2472.13.camel@edumazet-laptop>
On Fri, May 28, 2010 at 2:16 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 28 mai 2010 à 13:38 -0700, Ivan Novick a écrit :
>> sk_stream_wait_memory seems to be called when the send buffer is full
>> and the next send call does not complete until the send buffer
>> utilization goes down from 4,194,304 bytes to 2,814,968 bytes.
>>
>> This implies that the send that blocks on a full send buffer will not
>> complete until there is 1 meg of free space in the send buffer even
>> though the send could be accepted into the OS with only 128KB of free
>> space.
>>
>
> static void sock_def_write_space(struct sock *sk)
> {
> ...
> if ((atomic_read(&sk->sk_wmem_alloc) << 1) <= sk->sk_sndbuf) {
> ...
>
>
> Quick answer is : No, this is not tunable ( independantly than SNDBUF )
>
> SO_SNDLOWAT is not implemented on linux, yet (its value is : 1).
>
>
> Why would you want to wakeup your thread more than necessary ?
Cool. This helps me understand what is happening.
My user thread wants to wake up as soon as the OS can accept my data
so that it can continue doing work and interact with other components
in the system. This is an application issue, i can work around it now
that i have a better understanding of what the kernel is doing.
Cheers,
Ivan
^ permalink raw reply
* Re: Choppy TCP send performance
From: Eric Dumazet @ 2010-05-28 22:00 UTC (permalink / raw)
To: Ivan Novick; +Cc: netdev, Tim Heath
In-Reply-To: <AANLkTilZxoSEGOhmWdk2RbIGMmCMi2yNJm9rUwIzDIoL@mail.gmail.com>
Le vendredi 28 mai 2010 à 14:35 -0700, Ivan Novick a écrit :
> On Fri, May 28, 2010 at 2:16 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le vendredi 28 mai 2010 à 13:38 -0700, Ivan Novick a écrit :
> >> sk_stream_wait_memory seems to be called when the send buffer is full
> >> and the next send call does not complete until the send buffer
> >> utilization goes down from 4,194,304 bytes to 2,814,968 bytes.
> >>
> >> This implies that the send that blocks on a full send buffer will not
> >> complete until there is 1 meg of free space in the send buffer even
> >> though the send could be accepted into the OS with only 128KB of free
> >> space.
> >>
> >
> > static void sock_def_write_space(struct sock *sk)
> > {
> > ...
> > if ((atomic_read(&sk->sk_wmem_alloc) << 1) <= sk->sk_sndbuf) {
> > ...
> >
> >
> > Quick answer is : No, this is not tunable ( independantly than SNDBUF )
> >
> > SO_SNDLOWAT is not implemented on linux, yet (its value is : 1).
> >
> >
> > Why would you want to wakeup your thread more than necessary ?
>
> Cool. This helps me understand what is happening.
>
> My user thread wants to wake up as soon as the OS can accept my data
> so that it can continue doing work and interact with other components
> in the system. This is an application issue, i can work around it now
> that i have a better understanding of what the kernel is doing.
If you use poll() or select() before issuing your write(), I believe it
should be OK.
^ permalink raw reply
* Re: Choppy TCP send performance
From: Rick Jones @ 2010-05-28 22:08 UTC (permalink / raw)
To: Ivan Novick; +Cc: Eric Dumazet, netdev, Tim Heath
In-Reply-To: <AANLkTilZxoSEGOhmWdk2RbIGMmCMi2yNJm9rUwIzDIoL@mail.gmail.com>
Unless you think your application will run over 10G, or over a WAN, you
shouldn't need anywhere near the size of socket buffer you are getting via
autotuning to be able to achieve "link-rate" - link rate with a 1GbE LAN
connection can be achieved quite easily with a 256KB socket buffer.
The first test here is with autotuning going - disregard what netperf reports
for the socket buffer sizes here - it is calling getsockopt() before connect()
and before the end of the connection():
raj@spec-ptd2:~/netperf2_trunk$ src/netperf -H s9 -v 2 -l 30 -- -m 128K
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to s9.cup.hp.com
(16.89.132.29) port 0 AF_INET : histogram
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 131072 30.01 911.50
Alignment Offset Bytes Bytes Sends Bytes Recvs
Local Remote Local Remote Xfered Per Per
Send Recv Send Recv Send (avg) Recv (avg)
8 8 0 0 3.42e+09 131074.49 26090 11624.79 294176
Maximum
Segment
Size (bytes)
1448
Histogram of time spent in send() call.
UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
HUNDRED_USEC : 0: 3: 21578: 378: 94: 20: 3: 2: 0: 4
UNIT_MSEC : 0: 4: 2: 0: 0: 780: 3215: 6: 0: 1
TEN_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
HUNDRED_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
>100_SECS: 0
HIST_TOTAL: 26090
Next, we have netperf make an explicit setsockopt() call for 128KB socket
buffers, which will get us 256K. Notice that the bandwidth remains the same,
but the distribution of the time spent in send() changes. It gets squeezed more
towards the middle of the range from before.
<unk$ src/netperf -H s9 -v 2 -l 30 -- -m 128K -s 128K -S 128K
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to s9.cup.hp.com
(16.89.132.29) port 0 AF_INET : histogram
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
262142 262144 131072 30.00 911.91
Alignment Offset Bytes Bytes Sends Bytes Recvs
Local Remote Local Remote Xfered Per Per
Send Recv Send Recv Send (avg) Recv (avg)
8 8 0 0 3.42e+09 131074.74 26091 11361.40 301008
Maximum
Segment
Size (bytes)
1448
Histogram of time spent in send() call.
UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
HUNDRED_USEC : 0: 401: 64: 10: 0: 0: 1: 279: 10237: 3914
UNIT_MSEC : 0: 11149: 31: 0: 4: 0: 0: 0: 0: 0
TEN_MSEC : 0: 1: 0: 0: 0: 0: 0: 0: 0: 0
HUNDRED_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
>100_SECS: 0
HIST_TOTAL: 26091
happy benchmarking,
rick jones
Just for grins, netperf asking for 64K socket buffers:
<unk$ src/netperf -H s9 -v 2 -l 30 -- -m 128K -s 64K -S 64K
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to s9.cup.hp.com
(16.89.132.29) port 0 AF_INET : histogram
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
131072 131072 131072 30.00 921.12
Alignment Offset Bytes Bytes Sends Bytes Recvs
Local Remote Local Remote Xfered Per Per
Send Recv Send Recv Send (avg) Recv (avg)
8 8 0 0 3.454e+09 131074.33 26354 11399.69 303020
Maximum
Segment
Size (bytes)
1448
Histogram of time spent in send() call.
UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
HUNDRED_USEC : 0: 2: 0: 0: 0: 7: 2672: 1831: 19: 1
UNIT_MSEC : 0: 21811: 6: 0: 4: 0: 0: 0: 0: 0
TEN_MSEC : 0: 1: 0: 0: 0: 0: 0: 0: 0: 0
HUNDRED_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
>100_SECS: 0
HIST_TOTAL: 26354
^ permalink raw reply
* Re: Choppy TCP send performance
From: Ivan Novick @ 2010-05-28 22:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Tim Heath
In-Reply-To: <1275084055.2472.15.camel@edumazet-laptop>
On Fri, May 28, 2010 at 3:00 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 28 mai 2010 à 14:35 -0700, Ivan Novick a écrit :
>> On Fri, May 28, 2010 at 2:16 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > Le vendredi 28 mai 2010 à 13:38 -0700, Ivan Novick a écrit :
>> >> sk_stream_wait_memory seems to be called when the send buffer is full
>> >> and the next send call does not complete until the send buffer
>> >> utilization goes down from 4,194,304 bytes to 2,814,968 bytes.
>> >>
>> >> This implies that the send that blocks on a full send buffer will not
>> >> complete until there is 1 meg of free space in the send buffer even
>> >> though the send could be accepted into the OS with only 128KB of free
>> >> space.
>> >>
>> >
>> > static void sock_def_write_space(struct sock *sk)
>> > {
>> > ...
>> > if ((atomic_read(&sk->sk_wmem_alloc) << 1) <= sk->sk_sndbuf) {
>> > ...
>> >
>> >
>> > Quick answer is : No, this is not tunable ( independantly than SNDBUF )
>> >
>> > SO_SNDLOWAT is not implemented on linux, yet (its value is : 1).
>> >
>> >
>> > Why would you want to wakeup your thread more than necessary ?
>>
>> Cool. This helps me understand what is happening.
>>
>> My user thread wants to wake up as soon as the OS can accept my data
>> so that it can continue doing work and interact with other components
>> in the system. This is an application issue, i can work around it now
>> that i have a better understanding of what the kernel is doing.
>
> If you use poll() or select() before issuing your write(), I believe it
> should be OK.
From my tests select will not return until the same threshold is met
of free space: if ((atomic_read(&sk->sk_wmem_alloc) << 1) <=
sk->sk_sndbuf
I got that from systemtap output
Cheers,
Ivan
^ permalink raw reply
* Re: [PATCH 1/2] Export firmware assigned labels of network devices to sysfs
From: Greg KH @ 2010-05-28 22:27 UTC (permalink / raw)
To: Matt Domsch
Cc: K, Narendra, netdev@vger.kernel.org,
linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
Hargrave, Jordan, Rose, Charles, Nijhawan, Vijay
In-Reply-To: <20100528181100.GA12806@auslistsprd01.us.dell.com>
On Fri, May 28, 2010 at 01:11:00PM -0500, Matt Domsch wrote:
> On Fri, May 28, 2010 at 08:40:41AM -0700, Greg KH wrote:
> > On Fri, May 28, 2010 at 06:55:21AM -0500, K, Narendra wrote:
> > > +static const char dell_dsm_uuid[] = {
> >
> > Um, a dell specific uuid in a generic file? What happens when we need
> > to support another manufacturer?
> >
> > > + 0xD0, 0x37, 0xC9, 0xE5, 0x53, 0x35, 0x7A, 0x4D,
> > > + 0x91, 0x17, 0xEA, 0x4D, 0x19, 0xC3, 0x43, 0x4D
> > > +};
>
> This simply needs to be renamed. It's defined in the ECN, so will be
> part of the spec, and is not vendor-unique, but defined once for all
> implementations. It separates this _DSM function from others.
Ok, that makes a bit more sense.
Care to post that ECN publically? And no, the Linux Foundation does not
have a PCI-SIG membership, the PCI-SIG keeps forbidding it. Other
operating systems are allowed to join but not Linux. Strange but
true...
thanks,
greg k-h
^ permalink raw reply
* Re: Choppy TCP send performance
From: Ivan Novick @ 2010-05-28 22:28 UTC (permalink / raw)
To: Rick Jones; +Cc: Eric Dumazet, netdev, Tim Heath
In-Reply-To: <4C003EE5.6070602@hp.com>
On Fri, May 28, 2010 at 3:08 PM, Rick Jones <rick.jones2@hp.com> wrote:
>
> Unless you think your application will run over 10G, or over a WAN, you
> shouldn't need anywhere near the size of socket buffer you are getting via
> autotuning to be able to achieve "link-rate" - link rate with a 1GbE LAN
> connection can be achieved quite easily with a 256KB socket buffer.
>
> The first test here is with autotuning going - disregard what netperf
> reports for the socket buffer sizes here - it is calling getsockopt() before
> connect() and before the end of the connection():
>
> raj@spec-ptd2:~/netperf2_trunk$ src/netperf -H s9 -v 2 -l 30 -- -m 128K
> TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to s9.cup.hp.com
> (16.89.132.29) port 0 AF_INET : histogram
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 131072 30.01 911.50
>
> Alignment Offset Bytes Bytes Sends Bytes Recvs
> Local Remote Local Remote Xfered Per Per
> Send Recv Send Recv Send (avg) Recv (avg)
> 8 8 0 0 3.42e+09 131074.49 26090 11624.79 294176
>
> Maximum
> Segment
> Size (bytes)
> 1448
>
>
> Histogram of time spent in send() call.
> UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
> TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
> HUNDRED_USEC : 0: 3: 21578: 378: 94: 20: 3: 2: 0: 4
> UNIT_MSEC : 0: 4: 2: 0: 0: 780: 3215: 6: 0: 1
> TEN_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
> HUNDRED_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
> UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
> TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
>>100_SECS: 0
> HIST_TOTAL: 26090
>
>
> Next, we have netperf make an explicit setsockopt() call for 128KB socket
> buffers, which will get us 256K. Notice that the bandwidth remains the
> same, but the distribution of the time spent in send() changes. It gets
> squeezed more towards the middle of the range from before.
>
> <unk$ src/netperf -H s9 -v 2 -l 30 -- -m 128K -s 128K -S 128K
> TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to s9.cup.hp.com
> (16.89.132.29) port 0 AF_INET : histogram
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 262142 262144 131072 30.00 911.91
>
> Alignment Offset Bytes Bytes Sends Bytes Recvs
> Local Remote Local Remote Xfered Per Per
> Send Recv Send Recv Send (avg) Recv (avg)
> 8 8 0 0 3.42e+09 131074.74 26091 11361.40 301008
>
> Maximum
> Segment
> Size (bytes)
> 1448
>
>
> Histogram of time spent in send() call.
> UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
> TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
> HUNDRED_USEC : 0: 401: 64: 10: 0: 0: 1: 279: 10237: 3914
> UNIT_MSEC : 0: 11149: 31: 0: 4: 0: 0: 0: 0: 0
> TEN_MSEC : 0: 1: 0: 0: 0: 0: 0: 0: 0: 0
> HUNDRED_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
> UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
> TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
>>100_SECS: 0
> HIST_TOTAL: 26091
>
> happy benchmarking,
>
> rick jones
>
>
> Just for grins, netperf asking for 64K socket buffers:
>
> <unk$ src/netperf -H s9 -v 2 -l 30 -- -m 128K -s 64K -S 64K
> TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to s9.cup.hp.com
> (16.89.132.29) port 0 AF_INET : histogram
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 131072 131072 131072 30.00 921.12
>
> Alignment Offset Bytes Bytes Sends Bytes Recvs
> Local Remote Local Remote Xfered Per Per
> Send Recv Send Recv Send (avg) Recv (avg)
> 8 8 0 0 3.454e+09 131074.33 26354 11399.69 303020
>
> Maximum
> Segment
> Size (bytes)
> 1448
>
>
> Histogram of time spent in send() call.
> UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
> TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
> HUNDRED_USEC : 0: 2: 0: 0: 0: 7: 2672: 1831: 19: 1
> UNIT_MSEC : 0: 21811: 6: 0: 4: 0: 0: 0: 0: 0
> TEN_MSEC : 0: 1: 0: 0: 0: 0: 0: 0: 0: 0
> HUNDRED_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
> UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
> TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
>>100_SECS: 0
> HIST_TOTAL: 26354
>
I am not sure i understand your historgram output. But what i am
getting from your message is that my buffer may be too big. If i
reduce the buffer like you are saying down to 256K send buffer than
the code that checks if select or send should block:
if ((atomic_read(&sk->sk_wmem_alloc) << 1) <=
sk->sk_sndbuf
Would only block waiting for space of 128 KB free as compared to 1 Meg
free in my example.
Therefore reducing the max time for send calls (in theory).
Is this what you are getting at?
Cheers,
Ivan
^ permalink raw reply
* Re: Choppy TCP send performance
From: Rick Jones @ 2010-05-28 22:57 UTC (permalink / raw)
To: Ivan Novick; +Cc: Eric Dumazet, netdev, Tim Heath
In-Reply-To: <AANLkTilBPOQIb7ua7hl89_EqH9nZdL0XA9Y9bN7fjEfh@mail.gmail.com>
Ivan Novick wrote:
> On Fri, May 28, 2010 at 3:08 PM, Rick Jones <rick.jones2@hp.com> wrote:
>>Histogram of time spent in send() call.
>>UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
>>TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
>>HUNDRED_USEC : 0: 2: 0: 0: 0: 7: 2672: 1831: 19: 1
>>UNIT_MSEC : 0: 21811: 6: 0: 4: 0: 0: 0: 0: 0
>>TEN_MSEC : 0: 1: 0: 0: 0: 0: 0: 0: 0: 0
>>HUNDRED_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
>>UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
>>TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0
>>
>>>100_SECS: 0
>>
>>HIST_TOTAL: 26354
>>
>
>
> I am not sure i understand your historgram output.
For example, 21811 of the send() calls were 1 <= time < 2 milliseconds. 2672 of
the send calls were 6 <= time < 7 hundred microseconds. Etc etc.
> But what i am
> getting from your message is that my buffer may be too big. If i
> reduce the buffer like you are saying down to 256K send buffer than
> the code that checks if select or send should block:
>
> if ((atomic_read(&sk->sk_wmem_alloc) << 1) <=
> sk->sk_sndbuf
>
> Would only block waiting for space of 128 KB free as compared to 1 Meg
> free in my example.
>
> Therefore reducing the max time for send calls (in theory).
>
> Is this what you are getting at?
Yes.
As for the select/poll stuff, if you have a thread that wants to get to
something else, I would suggest marking the socket non-blocking, trying the
send(), if it completes cool, if not, remember what didn't get sent, do the
other thing(s) and come back. If you find you have time to sit and wait, go
ahead and call select/poll/epoll/whatever.
Or, if you want to make sure you wait in poll/select/whatnot no more than N
units of time, and that length of time is within the abilities of the call, use
the timeout parameter present in those.
rick jones
^ permalink raw reply
* Re: [PATCH] netdev/fec: fix ifconfig eth0 down hang issue
From: Wolfram Sang @ 2010-05-29 0:40 UTC (permalink / raw)
To: Bryan Wu
Cc: davem, afleming, s.hauer, gerg, amit.kucheria, netdev,
linux-kernel
In-Reply-To: <4BFFDDAC.7000909@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 565 bytes --]
> The performance drop issue still hangs in my brain. As soon as I have a new
> patch, could you please help to test? Or do you guys found any performance drop
> solution on your hardware? IIRC, you reported similar issue as us.
Sure thing, I will test it. We use your old patch meanwhile, but I haven't
looked into performance issues yet. We needed to solve other issues with this
board so far.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: Paul Mackerras @ 2010-05-29 2:16 UTC (permalink / raw)
To: Ben McKeegan
Cc: netdev, linux-ppp, Alan Cox, Alexander E. Patrakov,
Richard Hartmann, linux-kernel
In-Reply-To: <4BB31E00.8060204@netservers.co.uk>
On Wed, Mar 31, 2010 at 11:03:44AM +0100, Ben McKeegan wrote:
> I needed to do something similar a while back and I took a very
> different approach, which I think is more flexible. Rather than
> implement a new round-robin scheduler I simply introduced a target
> minimum fragment size into the fragment size calculation, as a per
> bundle parameter that can be configured via a new ioctl. This
> modifies the algorithm so that it tries to limit the number of
> fragments such that each fragment is at least the minimum size. If
> the minimum size is greater than the packet size it will not be
> fragmented all but will instead just get sent down the next
> available channel.
>
> A pppd plugin generates the ioctl call allowing this to be tweaked
> per connection. It is more flexible in that you can still have the
> larger packets fragmented if you wish.
I like this a lot better than the other proposed patch. It adds less
code because it uses the fact that ppp_mp_explode() already has a
round-robin capability using the ppp->nxchan field, plus it provides a
way to control it per bundle via pppd.
If you fix up the indentation issues (2-space indent in some of the
added code -- if you're using emacs, set c-basic-offset to 8), I'll
ack it and hopefully DaveM will pick it up.
Paul.
^ permalink raw reply
* [PATCH] bnx2: Fix IRQ failures during kdump.
From: Michael Chan @ 2010-05-29 3:24 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-pci
When switching from the crashed kernel to the kdump kernel without going
through PCI reset, IRQs may not work if a different IRQ mode is used on
the kdump kernel. The original IRQ mode used in the crashed kernel may
still be enabled and the new IRQ mode may not work. For example, it
will fail when going from MSI-X mode to MSI mode.
We fix this by disabling MSI/MSI-X and enabling INTX in bnx2_init_board().
pci_save_state() is also moved to the end of bnx2_init_board() after
all config register fixups (including the new IRQ fixups) have been done.
Export pci_msi_off() from drivers/pci/pci.c for this purpose.
Update bnx2 version to 2.0.16.
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2.c | 17 ++++++++++++++---
drivers/pci/pci.c | 1 +
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 188e356..1b8ba14 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -58,8 +58,8 @@
#include "bnx2_fw.h"
#define DRV_MODULE_NAME "bnx2"
-#define DRV_MODULE_VERSION "2.0.15"
-#define DRV_MODULE_RELDATE "May 4, 2010"
+#define DRV_MODULE_VERSION "2.0.16"
+#define DRV_MODULE_RELDATE "May 28, 2010"
#define FW_MIPS_FILE_06 "bnx2/bnx2-mips-06-5.0.0.j6.fw"
#define FW_RV2P_FILE_06 "bnx2/bnx2-rv2p-06-5.0.0.j3.fw"
#define FW_MIPS_FILE_09 "bnx2/bnx2-mips-09-5.0.0.j15.fw"
@@ -7877,7 +7877,6 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device *dev)
}
pci_set_master(pdev);
- pci_save_state(pdev);
bp->pm_cap = pci_find_capability(pdev, PCI_CAP_ID_PM);
if (bp->pm_cap == 0) {
@@ -7953,6 +7952,16 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device *dev)
bp->flags |= BNX2_FLAG_MSI_CAP;
}
+ /* When going from a crashed kernel to a kdump kernel without PCI
+ * reset, MSI/MSI-X may still be enabled. We need to disable
+ * MSI/MSI-X and enable INTX because the kdump driver may operate
+ * the device in a different IRQ mode.
+ */
+ if (bp->flags & (BNX2_FLAG_MSI_CAP | BNX2_FLAG_MSIX_CAP)) {
+ pci_msi_off(pdev);
+ pci_intx(pdev, 1);
+ }
+
/* 5708 cannot support DMA addresses > 40-bit. */
if (CHIP_NUM(bp) == CHIP_NUM_5708)
persist_dma_mask = dma_mask = DMA_BIT_MASK(40);
@@ -8188,6 +8197,8 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device *dev)
bp->timer.data = (unsigned long) bp;
bp->timer.function = bnx2_timer;
+ pci_save_state(pdev);
+
return 0;
err_out_unmap:
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 1df7c50..a46b49d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2294,6 +2294,7 @@ void pci_msi_off(struct pci_dev *dev)
pci_write_config_word(dev, pos + PCI_MSIX_FLAGS, control);
}
}
+EXPORT_SYMBOL(pci_msi_off);
#ifndef HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_SIZE
int pci_set_dma_max_seg_size(struct pci_dev *dev, unsigned int size)
--
1.6.4.GIT
^ permalink raw reply related
* Re: [PATCH 1/2] Export firmware assigned labels of network devices to sysfs
From: Domsch, Matt @ 2010-05-29 4:51 UTC (permalink / raw)
To: Greg KH
Cc: K, Narendra, netdev@vger.kernel.org,
linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
Hargrave, Jordan, Rose, Charles, Nijhawan, Vijay
In-Reply-To: <20100528222745.GA28678@kroah.com>
On Fri, May 28, 2010 at 05:27:45PM -0500, Greg KH wrote:
> On Fri, May 28, 2010 at 01:11:00PM -0500, Matt Domsch wrote:
> > On Fri, May 28, 2010 at 08:40:41AM -0700, Greg KH wrote:
> > > On Fri, May 28, 2010 at 06:55:21AM -0500, K, Narendra wrote:
> > > > +static const char dell_dsm_uuid[] = {
> > >
> > > Um, a dell specific uuid in a generic file? What happens when we need
> > > to support another manufacturer?
> > >
> > > > + 0xD0, 0x37, 0xC9, 0xE5, 0x53, 0x35, 0x7A, 0x4D,
> > > > + 0x91, 0x17, 0xEA, 0x4D, 0x19, 0xC3, 0x43, 0x4D
> > > > +};
> >
> > This simply needs to be renamed. It's defined in the ECN, so will be
> > part of the spec, and is not vendor-unique, but defined once for all
> > implementations. It separates this _DSM function from others.
>
> Ok, that makes a bit more sense.
>
> Care to post that ECN publically? And no, the Linux Foundation does not
> have a PCI-SIG membership, the PCI-SIG keeps forbidding it. Other
> operating systems are allowed to join but not Linux. Strange but
> true...
I'm looking into it, and should know more next week.
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* [Patch] r8169: use u32 instead of unsigned long
From: Junchang Wang @ 2010-05-29 4:01 UTC (permalink / raw)
To: romieu; +Cc: netdev
RTL_R32 should return value with 32-bit width. But "unsigned long"
implies u64 on some 64-bit platforms.
Signed-off-by: Junchang Wang <junchangwang@gmail.com>
---
Sorry for coding style flaw in previous email.
drivers/net/r8169.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 217e709..4234d6a 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -88,7 +88,7 @@ static const int multicast_filter_limit = 32;
#define RTL_W32(reg, val32) writel ((val32), ioaddr + (reg))
#define RTL_R8(reg) readb (ioaddr + (reg))
#define RTL_R16(reg) readw (ioaddr + (reg))
-#define RTL_R32(reg) ((unsigned long) readl (ioaddr + (reg)))
+#define RTL_R32(reg) ((u32) readl(ioaddr + (reg)))
enum mac_version {
RTL_GIGA_MAC_NONE = 0x00,
--
^ permalink raw reply related
* Re: [PATCH] bnx2: Fix IRQ failures during kdump.
From: David Miller @ 2010-05-29 5:33 UTC (permalink / raw)
To: mchan; +Cc: netdev, linux-pci
In-Reply-To: <1275103462-8527-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 28 May 2010 20:24:22 -0700
> When switching from the crashed kernel to the kdump kernel without going
> through PCI reset, IRQs may not work if a different IRQ mode is used on
> the kdump kernel. The original IRQ mode used in the crashed kernel may
> still be enabled and the new IRQ mode may not work. For example, it
> will fail when going from MSI-X mode to MSI mode.
>
> We fix this by disabling MSI/MSI-X and enabling INTX in bnx2_init_board().
>
> pci_save_state() is also moved to the end of bnx2_init_board() after
> all config register fixups (including the new IRQ fixups) have been done.
>
> Export pci_msi_off() from drivers/pci/pci.c for this purpose.
>
> Update bnx2 version to 2.0.16.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
I sincerely doubt that your's will be the only device which will
ever run into this issue. Therefore handling it manually in
each and every device driver, which is the trend you will be
setting with this patch, doesn't make much sense.
Any device which uses MSI in any way can run into this scenerio,
wherein the device will be left with MSI enabled when we leave the
crash kernel and jump into the kdump kernel.
So this needs to be handled generically in the PCI layer or similar.
I'm not applying this patch.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-05-28
From: David Miller @ 2010-05-29 6:01 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100528180952.GC2405-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Fri, 28 May 2010 14:09:53 -0400
> Here are a few small fixes intended for 2.6.35. Included are a null
> pointer dereference fix, and a use-after-free fix, as well as some more
> minor stuff. It also include the revert of a earlier patch that I
> inadvertantly merged out of order, effectively creating a bug rather
> than fixing one. The reverted patch will now be pointed at 2.6.36
> instead.
>
> Please let me know if there are problems!
Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] IPv6: fix Mobile IPv6 regression
From: David Miller @ 2010-05-29 6:03 UTC (permalink / raw)
To: brian.haley; +Cc: arno, otts, yoshfuji, jolsa, netdev
In-Reply-To: <4C0008C7.7020302@hp.com>
From: Brian Haley <brian.haley@hp.com>
Date: Fri, 28 May 2010 14:17:43 -0400
> Commit f4f914b5 (net: ipv6 bind to device issue) caused
> a regression with Mobile IPv6 when it changed the meaning
> of fl->oif to become a strict requirement of the route
> lookup. Instead, only force strict mode when
> sk->sk_bound_dev_if is set on the calling socket, getting
> the intended behavior and fixing the regression.
>
> Tested-by: Arnaud Ebalard <arno@natisbad.org>
> Signed-off-by: Brian Haley <brian.haley@hp.com>
Applied, and queued for -stable, thanks for fixing this.
^ permalink raw reply
* Re: [PATCH] bnx2: Fix IRQ failures during kdump.
From: Grant Grundler @ 2010-05-29 6:45 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev, linux-pci
In-Reply-To: <1275103462-8527-1-git-send-email-mchan@broadcom.com>
On Fri, May 28, 2010 at 08:24:22PM -0700, Michael Chan wrote:
> When switching from the crashed kernel to the kdump kernel without going
> through PCI reset, IRQs may not work if a different IRQ mode is used on
> the kdump kernel. The original IRQ mode used in the crashed kernel may
> still be enabled and the new IRQ mode may not work. For example, it
> will fail when going from MSI-X mode to MSI mode.
>
> We fix this by disabling MSI/MSI-X and enabling INTX in bnx2_init_board().
>
> pci_save_state() is also moved to the end of bnx2_init_board() after
> all config register fixups (including the new IRQ fixups) have been done.
>
> Export pci_msi_off() from drivers/pci/pci.c for this purpose.
>
> Update bnx2 version to 2.0.16.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> ---
> drivers/net/bnx2.c | 17 ++++++++++++++---
> drivers/pci/pci.c | 1 +
> 2 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
> index 188e356..1b8ba14 100644
> --- a/drivers/net/bnx2.c
> +++ b/drivers/net/bnx2.c
> @@ -58,8 +58,8 @@
> #include "bnx2_fw.h"
>
> #define DRV_MODULE_NAME "bnx2"
> -#define DRV_MODULE_VERSION "2.0.15"
> -#define DRV_MODULE_RELDATE "May 4, 2010"
> +#define DRV_MODULE_VERSION "2.0.16"
> +#define DRV_MODULE_RELDATE "May 28, 2010"
> #define FW_MIPS_FILE_06 "bnx2/bnx2-mips-06-5.0.0.j6.fw"
> #define FW_RV2P_FILE_06 "bnx2/bnx2-rv2p-06-5.0.0.j3.fw"
> #define FW_MIPS_FILE_09 "bnx2/bnx2-mips-09-5.0.0.j15.fw"
> @@ -7877,7 +7877,6 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device *dev)
> }
>
> pci_set_master(pdev);
> - pci_save_state(pdev);
>
> bp->pm_cap = pci_find_capability(pdev, PCI_CAP_ID_PM);
> if (bp->pm_cap == 0) {
> @@ -7953,6 +7952,16 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device *dev)
> bp->flags |= BNX2_FLAG_MSI_CAP;
> }
>
> + /* When going from a crashed kernel to a kdump kernel without PCI
> + * reset, MSI/MSI-X may still be enabled. We need to disable
> + * MSI/MSI-X and enable INTX because the kdump driver may operate
> + * the device in a different IRQ mode.
> + */
> + if (bp->flags & (BNX2_FLAG_MSI_CAP | BNX2_FLAG_MSIX_CAP)) {
> + pci_msi_off(pdev);
> + pci_intx(pdev, 1);
Does the driver have to register a different Interrupt handler when
switching from MSI(-X) to IRQ interrupts?
(I'm thinking of IRQ interrupts might have DMA vs IRQ ordering dependency)
If that's true, then this can't be handled in the generic PCI layer (as
suggested by davem) unless the device driver could register multiple interrupt
handlers even if only one is active at a time.
thanks,
grant
> + }
> +
> /* 5708 cannot support DMA addresses > 40-bit. */
> if (CHIP_NUM(bp) == CHIP_NUM_5708)
> persist_dma_mask = dma_mask = DMA_BIT_MASK(40);
> @@ -8188,6 +8197,8 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device *dev)
> bp->timer.data = (unsigned long) bp;
> bp->timer.function = bnx2_timer;
>
> + pci_save_state(pdev);
> +
> return 0;
>
> err_out_unmap:
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 1df7c50..a46b49d 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2294,6 +2294,7 @@ void pci_msi_off(struct pci_dev *dev)
> pci_write_config_word(dev, pos + PCI_MSIX_FLAGS, control);
> }
> }
> +EXPORT_SYMBOL(pci_msi_off);
>
> #ifndef HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_SIZE
> int pci_set_dma_max_seg_size(struct pci_dev *dev, unsigned int size)
> --
> 1.6.4.GIT
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] bnx2: Fix IRQ failures during kdump.
From: David Miller @ 2010-05-29 6:50 UTC (permalink / raw)
To: grundler; +Cc: mchan, netdev, linux-pci
In-Reply-To: <20100529064512.GA21336@lackof.org>
From: Grant Grundler <grundler@parisc-linux.org>
Date: Sat, 29 May 2010 00:45:12 -0600
> If that's true, then this can't be handled in the generic PCI layer (as
> suggested by davem) unless the device driver could register multiple interrupt
> handlers even if only one is active at a time.
The generic PCI layer very well can turn off MSI on all devices
when it starts up or a device is plugged in.
That's all he is doing.
Drivers essentially expect that the device comes up in INTX mode
when the driver probes the device. All his change is doing
is forcing that to be true, and there is no reason the generic
PCI code can't do that.
^ permalink raw reply
* Re: [Patch] r8169: use u32 instead of unsigned long
From: David Miller @ 2010-05-29 6:53 UTC (permalink / raw)
To: junchangwang; +Cc: romieu, netdev
In-Reply-To: <20100529040111.GA28225@host-a-55.ustcsz.edu.cn>
From: Junchang Wang <junchangwang@gmail.com>
Date: Sat, 29 May 2010 12:01:11 +0800
> RTL_R32 should return value with 32-bit width. But "unsigned long"
> implies u64 on some 64-bit platforms.
>
> Signed-off-by: Junchang Wang <junchangwang@gmail.com>
I fail to see why there is a need to cast the return value
of readl() at all.
It returns a 32-bit integer on all platforms.
Secondly, 8139too.c has the same unnecessary cast.
So the thing to do is to kill the casts completely from both
drivers defining this register read macro.
^ permalink raw reply
* Re: [PATCH] net: add rtnl assertion to linkwatch_run_queue
From: David Miller @ 2010-05-29 7:01 UTC (permalink / raw)
To: dkirjanov; +Cc: eric.dumazet, shemminger, herbert, kaber, netdev
In-Reply-To: <20100527055100.GA21234@hera.kernel.org>
From: Denis Kirjanov <dkirjanov@hera.kernel.org>
Date: Thu, 27 May 2010 05:51:00 +0000
> Add RTNL assertion to linkwatch_run_queue since function
> must be called with semaphore held
>
> Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
This function is exported purely for netdev_wait_allrefs()'s sake
and for no other purpose.
In fact, I'd say this is entirely a private functional interface
specifically built for generic network interface tear-down.
If you are trying to use this function in another context, that's
something you need to discuss with us first before we start peppering
it with various assertions.
I am not applying this patch.
^ permalink raw reply
* Re: [PATCH net-next]atl1c: Add AR8151 v2 support and change L0s/L1 routine
From: David Miller @ 2010-05-29 7:06 UTC (permalink / raw)
To: jie.yang; +Cc: Luis.Rodriguez, netdev, linux-kernel
In-Reply-To: <12750324381174-git-send-email-jie.yang@atheros.com>
From: <jie.yang@atheros.com>
Date: Fri, 28 May 2010 15:40:38 +0800
> From: Jie.Yang@atheros.com
>
> Add AR8151 v2.0 Gigabit 1000 support
> Change jumbo frame size to 6K
> Update L0s/L1 rountine
> Update atl1c_suspend routine.
>
> Signed-off-by: Jie.Yang@atheros.com
Your commit log message is way too terse.
You should describe in detail what your changes are.
Saying "Update L0s/L1 routine" doesn't tell us exactly what change
you are making. And more importantly, it does not tell us why you
are making this change.
This also applied to "update atl1c_suspend routine" You have to
list exactly change you are making, and why.
You should be able to write a full paragraph explaining what each
change is, and the reason for that change. This means 4 to 5 full
english sentences, which means more than 3 or 4 words in each
sentence.
Do not try to put as minimal amount of information into your commit
messages as possible, instead strive to put too much information.
Be long winded, and verbose, because you cannot predict what details
of your change and reasoning will be important to someone in the future.
Because some day someone will read your commit patch and wonder the
reasons why you made your changes.
I am not applying this patch until the commit message is made more
verbose and reasonable.
^ permalink raw reply
* Re: [PATCH] packet_mmap: expose hw packet timestamps to network packet capture utilities
From: David Miller @ 2010-05-29 7:11 UTC (permalink / raw)
To: scott.a.mcmillan; +Cc: netdev, tcpdump-workers
In-Reply-To: <09ED21B37E0F694688A2317C4FED9ED3046E53F595@azsmsx504.amr.corp.intel.com>
From: "Mcmillan, Scott A" <scott.a.mcmillan@intel.com>
Date: Thu, 27 May 2010 09:58:19 -0700
> There was no negative feedback on this RFC, and the corresponding
> tcpdump patch was well received. Please apply.
I think lack of feedback is not an indication of agreement.
You sent that patch right around the openning of the merge window when
people (myself included) are already overwhelmed with existing tasks.
New patches aren't likely to get serious consideration during that
time.
^ permalink raw reply
* Re: [PATCH] skb: make skb_recycle_check() return a bool value
From: David Miller @ 2010-05-29 7:12 UTC (permalink / raw)
To: xiaosuo; +Cc: eric.dumazet, linux-kernel, netdev
In-Reply-To: <1274970803-8051-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Thu, 27 May 2010 22:33:23 +0800
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net/fec: fix pm to survive to suspend/resume
From: David Miller @ 2010-05-29 7:15 UTC (permalink / raw)
To: eric; +Cc: s.hauer, sshtylyov, linux-arm-kernel, fabioestevam, netdev
In-Reply-To: <1274982828-13082-1-git-send-email-eric@eukrea.com>
From: Eric Bénard <eric@eukrea.com>
Date: Thu, 27 May 2010 19:53:48 +0200
> * with this patch, if the connection if active before suspend, it
> will be active after resume.
> * before this patch, it was necessary to close the interface and
> reopen it to recover the connection.
>
> Signed-off-by: Eric Bénard <eric@eukrea.com>
On resume the PHY should be reset and the link renegotiated (or set to
a fixed speed/duplex if set by the user via ethtool) just like as
happens on ->open().
You seem to be avoiding that here.
If the PHY is not functioning properly after the ->resume() triggered
reset, fix that instead.
I'm not applying this patch, it doesn't look the right thing to do at
all.
^ 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