* [PATCH v4] Proportional Rate Reduction for TCP.
From: Nandita Dukkipati @ 2011-08-22 6:21 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Tom Herbert, Matt Mathis, Yuchung Cheng,
Nandita Dukkipati
In-Reply-To: <1313803779-6221-1-git-send-email-nanditad@google.com>
This patch implements Proportional Rate Reduction (PRR) for TCP.
PRR is an algorithm that determines TCP's sending rate in fast
recovery. PRR avoids excessive window reductions and aims for
the actual congestion window size at the end of recovery to be as
close as possible to the window determined by the congestion control
algorithm. PRR also improves accuracy of the amount of data sent
during loss recovery.
The patch implements the recommended flavor of PRR called PRR-SSRB
(Proportional rate reduction with slow start reduction bound) and
replaces the existing rate halving algorithm. PRR improves upon the
existing Linux fast recovery under a number of conditions including:
1) burst losses where the losses implicitly reduce the amount of
outstanding data (pipe) below the ssthresh value selected by the
congestion control algorithm and,
2) losses near the end of short flows where application runs out of
data to send.
As an example, with the existing rate halving implementation a single
loss event can cause a connection carrying short Web transactions to
go into the slow start mode after the recovery. This is because during
recovery Linux pulls the congestion window down to packets_in_flight+1
on every ACK. A short Web response often runs out of new data to send
and its pipe reduces to zero by the end of recovery when all its packets
are drained from the network. Subsequent HTTP responses using the same
connection will have to slow start to raise cwnd to ssthresh. PRR on
the other hand aims for the cwnd to be as close as possible to ssthresh
by the end of recovery.
A description of PRR and a discussion of its performance can be found at
the following links:
- IETF Draft:
http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-01
- IETF Slides:
http://www.ietf.org/proceedings/80/slides/tcpm-6.pdf
http://tools.ietf.org/agenda/81/slides/tcpm-2.pdf
- Paper to appear in Internet Measurements Conference (IMC) 2011:
Improving TCP Loss Recovery
Nandita Dukkipati, Matt Mathis, Yuchung Cheng
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
---
Changelog since v3:
- Removed the fallback of cwnd to 1 in tcp_update_cwnd_recovery(), for the extremely
unlikely event that tp->prior_cwnd takes on a value of 0 (bug outside of PRR).
Changelog since v2:
- Used div_u64 in tcp_update_cwnd_in_recovery() to ensure portable 64-bit division.
- Removed an empty line in tcp_complete_cwr().
Changelog since v1:
- Took care of overflow for large congestion windows in tcp_update_cwnd_in_recovery().
- Renamed prr_cwnd to prior_cwnd.
- Renamed pkts_delivered to newly_acked_sacked.
include/linux/tcp.h | 4 +++
net/ipv4/tcp_input.c | 58 +++++++++++++++++++++++++++++++++++++++++++-----
net/ipv4/tcp_output.c | 7 +++++-
3 files changed, 62 insertions(+), 7 deletions(-)
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 531ede8..6b63b31 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -379,6 +379,10 @@ struct tcp_sock {
u32 snd_cwnd_clamp; /* Do not allow snd_cwnd to grow above this */
u32 snd_cwnd_used;
u32 snd_cwnd_stamp;
+ u32 prior_cwnd; /* Congestion window at start of Recovery. */
+ u32 prr_delivered; /* Number of newly delivered packets to
+ * receiver in Recovery. */
+ u32 prr_out; /* Total number of pkts sent during Recovery. */
u32 rcv_wnd; /* Current receiver window */
u32 write_seq; /* Tail(+1) of data held in tcp send buffer */
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index ea0d218..385c470 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2830,9 +2830,13 @@ static int tcp_try_undo_loss(struct sock *sk)
static inline void tcp_complete_cwr(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
- /* Do not moderate cwnd if it's already undone in cwr or recovery */
- if (tp->undo_marker && tp->snd_cwnd > tp->snd_ssthresh) {
- tp->snd_cwnd = tp->snd_ssthresh;
+
+ /* Do not moderate cwnd if it's already undone in cwr or recovery. */
+ if (tp->undo_marker) {
+ if (inet_csk(sk)->icsk_ca_state == TCP_CA_CWR)
+ tp->snd_cwnd = min(tp->snd_cwnd, tp->snd_ssthresh);
+ else /* PRR */
+ tp->snd_cwnd = tp->snd_ssthresh;
tp->snd_cwnd_stamp = tcp_time_stamp;
}
tcp_ca_event(sk, CA_EVENT_COMPLETE_CWR);
@@ -2950,6 +2954,38 @@ void tcp_simple_retransmit(struct sock *sk)
}
EXPORT_SYMBOL(tcp_simple_retransmit);
+/* This function implements the PRR algorithm, specifcally the PRR-SSRB
+ * (proportional rate reduction with slow start reduction bound) as described in
+ * http://www.ietf.org/id/draft-mathis-tcpm-proportional-rate-reduction-01.txt.
+ * It computes the number of packets to send (sndcnt) based on packets newly
+ * delivered:
+ * 1) If the packets in flight is larger than ssthresh, PRR spreads the
+ * cwnd reductions across a full RTT.
+ * 2) If packets in flight is lower than ssthresh (such as due to excess
+ * losses and/or application stalls), do not perform any further cwnd
+ * reductions, but instead slow start up to ssthresh.
+ */
+static void tcp_update_cwnd_in_recovery(struct sock *sk, int newly_acked_sacked,
+ int fast_rexmit, int flag)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ int sndcnt = 0;
+ int delta = tp->snd_ssthresh - tcp_packets_in_flight(tp);
+
+ if (tcp_packets_in_flight(tp) > tp->snd_ssthresh) {
+ u64 dividend = (u64)tp->snd_ssthresh * tp->prr_delivered +
+ tp->prior_cwnd - 1;
+ sndcnt = div_u64(dividend, tp->prior_cwnd) - tp->prr_out;
+ } else {
+ sndcnt = min_t(int, delta,
+ max_t(int, tp->prr_delivered - tp->prr_out,
+ newly_acked_sacked) + 1);
+ }
+
+ sndcnt = max(sndcnt, (fast_rexmit ? 1 : 0));
+ tp->snd_cwnd = tcp_packets_in_flight(tp) + sndcnt;
+}
+
/* Process an event, which can update packets-in-flight not trivially.
* Main goal of this function is to calculate new estimate for left_out,
* taking into account both packets sitting in receiver's buffer and
@@ -2961,7 +2997,8 @@ EXPORT_SYMBOL(tcp_simple_retransmit);
* It does _not_ decide what to send, it is made in function
* tcp_xmit_retransmit_queue().
*/
-static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
+static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked,
+ int newly_acked_sacked, int flag)
{
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
@@ -3111,13 +3148,17 @@ static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
tp->bytes_acked = 0;
tp->snd_cwnd_cnt = 0;
+ tp->prior_cwnd = tp->snd_cwnd;
+ tp->prr_delivered = 0;
+ tp->prr_out = 0;
tcp_set_ca_state(sk, TCP_CA_Recovery);
fast_rexmit = 1;
}
if (do_lost || (tcp_is_fack(tp) && tcp_head_timedout(sk)))
tcp_update_scoreboard(sk, fast_rexmit);
- tcp_cwnd_down(sk, flag);
+ tp->prr_delivered += newly_acked_sacked;
+ tcp_update_cwnd_in_recovery(sk, newly_acked_sacked, fast_rexmit, flag);
tcp_xmit_retransmit_queue(sk);
}
@@ -3632,6 +3673,8 @@ static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag)
u32 prior_in_flight;
u32 prior_fackets;
int prior_packets;
+ int prior_sacked = tp->sacked_out;
+ int newly_acked_sacked = 0;
int frto_cwnd = 0;
/* If the ack is older than previous acks
@@ -3703,6 +3746,9 @@ static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag)
/* See if we can take anything off of the retransmit queue. */
flag |= tcp_clean_rtx_queue(sk, prior_fackets, prior_snd_una);
+ newly_acked_sacked = (prior_packets - prior_sacked) -
+ (tp->packets_out - tp->sacked_out);
+
if (tp->frto_counter)
frto_cwnd = tcp_process_frto(sk, flag);
/* Guarantee sacktag reordering detection against wrap-arounds */
@@ -3715,7 +3761,7 @@ static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag)
tcp_may_raise_cwnd(sk, flag))
tcp_cong_avoid(sk, ack, prior_in_flight);
tcp_fastretrans_alert(sk, prior_packets - tp->packets_out,
- flag);
+ newly_acked_sacked, flag);
} else {
if ((flag & FLAG_DATA_ACKED) && !frto_cwnd)
tcp_cong_avoid(sk, ack, prior_in_flight);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 882e0b0..ca50408 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1796,11 +1796,13 @@ static int tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
tcp_event_new_data_sent(sk, skb);
tcp_minshall_update(tp, mss_now, skb);
- sent_pkts++;
+ sent_pkts += tcp_skb_pcount(skb);
if (push_one)
break;
}
+ if (inet_csk(sk)->icsk_ca_state == TCP_CA_Recovery)
+ tp->prr_out += sent_pkts;
if (likely(sent_pkts)) {
tcp_cwnd_validate(sk);
@@ -2294,6 +2296,9 @@ begin_fwd:
return;
NET_INC_STATS_BH(sock_net(sk), mib_idx);
+ if (inet_csk(sk)->icsk_ca_state == TCP_CA_Recovery)
+ tp->prr_out += tcp_skb_pcount(skb);
+
if (skb == tcp_write_queue_head(sk))
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
inet_csk(sk)->icsk_rto,
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH v2] Proportional Rate Reduction for TCP.
From: Nandita Dukkipati @ 2011-08-22 6:21 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: David S. Miller, Netdev, Tom Herbert, Matt Mathis, Yuchung Cheng
In-Reply-To: <alpine.DEB.2.00.1108201534590.24318@melkinpaasi.cs.helsinki.fi>
On Sat, Aug 20, 2011 at 5:41 AM, Ilpo Järvinen
<ilpo.jarvinen@helsinki.fi> wrote:
> On Fri, 19 Aug 2011, Nandita Dukkipati wrote:
>
>> Forgot to turn off gmail's rich formatting, so re-sending to the list.
>>
>> On Fri, Aug 19, 2011 at 3:25 AM, Ilpo Järvinen
>> <ilpo.jarvinen@helsinki.fi> wrote:
>> >
>> > On Fri, 19 Aug 2011, Nandita Dukkipati wrote:
>> >
>> > > +static void tcp_update_cwnd_in_recovery(struct sock *sk, int newly_acked_sacked,
>> > > + int fast_rexmit, int flag)
>> > > +{
>> > > + struct tcp_sock *tp = tcp_sk(sk);
>> > > + int sndcnt = 0;
>> > > + int delta = tp->snd_ssthresh - tcp_packets_in_flight(tp);
>> > > +
>> > > + if (tcp_packets_in_flight(tp) > tp->snd_ssthresh) {
>> > > + if (WARN_ON(!tp->prior_cwnd))
>> > > + tp->prior_cwnd = 1;
>> >
>> > This should still be made larger to avoid problems if it ever will be
>> > needed.
>>
>> I am letting the value remain at 1, mainly because this is the valid
>> lowest non-zero value for snd_cwnd to take on. The main purpose of
>> this code is to catch any lurking bug outside of PRR which results in
>> an undesirable divide by 0 in PRR. I would like to fix that bug if I
>> find this code is executed.
>
> NACK, until this value is at least 2 * tp->snd_ssthresh. Or alternatively
> the fallback is removed so that we DBZ and do not end up wrecking the
> network.
If prior_cwnd is suspect at this point, snd_ssthresh cannot be trusted either.
So it appears to me that it's best to remove the fallback and spare
the network.
Done in patch v4.
Nandita
>
> Other than that I'm ok with the patch (assuming the branches I brought
> up earlier is ok for everybody else).
>
>
> --
> i.
^ permalink raw reply
* Re: linux kernel development
From: Américo Wang @ 2011-08-22 4:53 UTC (permalink / raw)
To: Niloofar Fazlollahi; +Cc: netdev, linux-kernel, linux-next
In-Reply-To: <CAK8ka9wP_V7ngtR0jv7T3vNZoTep9c18=AgRSe9efYAyXejUPg@mail.gmail.com>
On Mon, Aug 22, 2011 at 12:51 PM, Niloofar Fazlollahi
<nfazlollahi@gmail.com> wrote:
> Hi,
>
> I have a generic question and appreciate your kind response.
>
> What is the process and requirements for getting the linux kernel community
>
> approval to commit a code into linux kernel (related to networking - TCP).
Hello,
Please read the documents in Documentation/development-process/ directory
of the kernel source code.
Thanks.
^ permalink raw reply
* linux kernel development
From: Niloofar Fazlollahi @ 2011-08-22 4:51 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, linux-next
In-Reply-To: <CAK8ka9y1VhMzS0X2GSEg4AQzSMPwOkS3HQxBuX4t-Rp-_OwDow@mail.gmail.com>
Hi,
I have a generic question and appreciate your kind response.
What is the process and requirements for getting the linux kernel community
approval to commit a code into linux kernel (related to networking - TCP).
Regards
Niloofar F
^ permalink raw reply
* Re: [PATCH 0/2] Improve sequence number generation.
From: George Spelvin @ 2011-08-22 2:06 UTC (permalink / raw)
To: linux, tytso; +Cc: dan, davem, gerrit, herbert, linux-kernel, mpm, netdev, w
In-Reply-To: <20110821032753.GA8992@thunk.org>
> Here's a random thought --- it won't help on anything other than
> modern x86's, but who's to say we have to use the same algorithm on
> all platforms?
We absolutely do not. With 15 64-bit registers, there are a lot more
efficient algorithms available than x86-32.
Here are my current timing experiments trying to find an efficient
hash for that case. Timings are for 100,000 iterations, so these are
generally in the 100-200 cycles range per operation.
This is 32-bit code, even though it's running on 64-bit machines.
The first 3 are various MD5 implementations (standard, with the k[]
constants in an external array, with the input and K values scheduled
separately so it's a 64-word linear fetch while running).
Then are three similar variants of two-at-a-time MD5 computation.
The lines reporting 0 time are the second outputs.
The last two MD5 timings (9 and 10) are the current half_md4_transform
and twothirdsMD4Transform. Those are the timing figures to match,
or preferably beat.
ChaCha is 8 rounds, and simply not fast enough.
The Skein192 (to be renamed; it's NOT approved by the designers!) is a
36-round, 6x32-bit variant of the SHA-3 candidate Skein. 0 is C code,
1 and 2 are rolled up assembly variants, 3 and 4 are unrolled assembly,
and 5 is unrolled assembly that also drops the tweak words. (Which is
hardly important if we're only hashing one block.)
That, as you can see, is about half the time of MD5 and competitive with
the 2/3 MD4. And probably considerably more secure. (It's basically a
secure 192-bit hash with zero margin; I could maybe shave another couple
of rounds and still have 128-bit security.)
Shabal is a supposedly-fast SHA-3 candidate that made it to round 2,
just to see what the timing is like. The second line is a half-size
variant that works on 8 as opposed to 16 words at a time.
2.4 GHz Phenom, hot cache:
MD5 (& half MD4) implementations:
0: 36912577 cycles 16d174cf 10a7082f e1a2b897 3faddc63
1: 36937728 cycles 16d174cf 10a7082f e1a2b897 3faddc63
2: 37354723 cycles 16d174cf 10a7082f e1a2b897 3faddc63
3: 58866027 cycles 16d174cf 10a7082f e1a2b897 3faddc63
4: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
5: 96074375 cycles 16d174cf 10a7082f e1a2b897 3faddc63
6: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
7: 101722571 cycles 16d174cf 10a7082f e1a2b897 3faddc63
8: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
9: 12321905 cycles b4b721c6 5635b583 b06c6474 c9871bee
10: 18038018 cycles 336f8820 5565aa9b 0133a23a 0b62780f
ChaCha implementations:
0: 37345090 cycles 751ddf6a 6977b031 60730a4f c1e2d89e
1: 30782411 cycles d5fec2fe a8937844 33da9645 cbff3484
Skein192 implementations:
0: 30343213 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
1: 22137253 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
2: 22439643 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
3: 18189990 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
4: 19025781 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
5: 17335443 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
Shabal implementations:
0: 177585782 cycles 6c192c71 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
1: 88048716 cycles 51e5dab0 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
2.4 GHz Phenom, "cool cache": Run each of the 20 code paths once, then repeat 100,000 times.
MD5 (& half MD4) implementations:
0: 43746107 cycles 16d174cf 10a7082f e1a2b897 3faddc63
1: 43682485 cycles 16d174cf 10a7082f e1a2b897 3faddc63
2: 43554706 cycles 16d174cf 10a7082f e1a2b897 3faddc63
3: 65376283 cycles 16d174cf 10a7082f e1a2b897 3faddc63
4: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
5: 105050654 cycles 16d174cf 10a7082f e1a2b897 3faddc63
6: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
7: 109949761 cycles 16d174cf 10a7082f e1a2b897 3faddc63
8: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
9: 19284802 cycles b4b721c6 5635b583 b06c6474 c9871bee
10: 24359312 cycles 336f8820 5565aa9b 0133a23a 0b62780f
ChaCha implementations:
0: 46379423 cycles 751ddf6a 6977b031 60730a4f c1e2d89e
1: 38641131 cycles d5fec2fe a8937844 33da9645 cbff3484
Skein192 implementations:
0: 38125833 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
1: 31800936 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
2: 29010869 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
3: 25627838 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
4: 25913924 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
5: 24318110 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
Shabal implementations:
0: 185723030 cycles 6c192c71 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
1: 92834811 cycles 51e5dab0 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
2.67 GHz i7 (Xeon W3520), hot cache:
MD5 (& half MD4) implementations:
0: 36919956 cycles 16d174cf 10a7082f e1a2b897 3faddc63
1: 37156578 cycles 16d174cf 10a7082f e1a2b897 3faddc63
2: 35044283 cycles 16d174cf 10a7082f e1a2b897 3faddc63
3: 61506553 cycles 16d174cf 10a7082f e1a2b897 3faddc63
4: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
5: 97228616 cycles 16d174cf 10a7082f e1a2b897 3faddc63
6: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
7: 102025434 cycles 16d174cf 10a7082f e1a2b897 3faddc63
8: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
9: 11890788 cycles b4b721c6 5635b583 b06c6474 c9871bee
10: 19542853 cycles 336f8820 5565aa9b 0133a23a 0b62780f
ChaCha implementations:
0: 32864931 cycles 751ddf6a 6977b031 60730a4f c1e2d89e
1: 28502254 cycles d5fec2fe a8937844 33da9645 cbff3484
Skein192 implementations:
0: 28894544 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
1: 25963843 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
2: 26394942 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
3: 22960214 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
4: 22458045 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
5: 21020691 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
Shabal implementations:
0: 107339671 cycles 6c192c71 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
1: 52250187 cycles 51e5dab0 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
2.67 GHz i7 (Xeon W3520), cool cache:
MD5 (& half MD4) implementations:
0: 38680693 cycles 16d174cf 10a7082f e1a2b897 3faddc63
1: 37812504 cycles 16d174cf 10a7082f e1a2b897 3faddc63
2: 35577261 cycles 16d174cf 10a7082f e1a2b897 3faddc63
3: 60584516 cycles 16d174cf 10a7082f e1a2b897 3faddc63
4: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
5: 96525869 cycles 16d174cf 10a7082f e1a2b897 3faddc63
6: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
7: 98360974 cycles 16d174cf 10a7082f e1a2b897 3faddc63
8: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
9: 13622987 cycles b4b721c6 5635b583 b06c6474 c9871bee
10: 20895171 cycles 336f8820 5565aa9b 0133a23a 0b62780f
ChaCha implementations:
0: 34210571 cycles 751ddf6a 6977b031 60730a4f c1e2d89e
1: 29135985 cycles d5fec2fe a8937844 33da9645 cbff3484
Skein192 implementations:
0: 29621108 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
1: 27885244 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
2: 26022084 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
3: 22360719 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
4: 24639107 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
5: 21072150 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
Shabal implementations:
0: 105186652 cycles 6c192c71 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
1: 57009351 cycles 51e5dab0 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
^ permalink raw reply
* linux-next: manual merge of the net tree with the tree
From: Stephen Rothwell @ 2011-08-22 1:51 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Josh Boyer, Niklaus Giger, Tony Breeds
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
Hi all,
Today's linux-next merge of the net tree got a conflict in
arch/powerpc/configs/40x/hcu4_defconfig between commit 9fcd768d0cc8
("powerpc/40x: Remove obsolete HCU4 board") from the 4xx tree and commit
3b3bceef26f8 ("net: fix IBM EMAC driver after rename") from the net tree.
The former commit removes the file, so I just did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-22 1:30 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher, mikey,
torvalds, akpm, ppc-dev, Benjamin Herrenschmidt, Paul Mackerras
In-Reply-To: <20110817.225356.1790362313048139752.davem@davemloft.net>
Hi Dave,
On Wed, 17 Aug 2011 22:53:56 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 18 Aug 2011 15:22:14 +1000
>
> > Mikey asks: Will Dave take these updates if we get Acks from the
> > maintainers? :-)
>
> I'm more than happy to :-)
Here's what I am applying as a merge fixup to the net tree today so that
my ppc64_defconfig builds actually build more or less the same set of
drivers as before this rearrangement.
This has no Acks yet, but produces a very similar .config to what we had
previously.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 22 Aug 2011 11:23:56 +1000
Subject: [PATCH] powerpc: update ppc64_defconfig for net device movement
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/configs/ppc64_defconfig | 71 +++++++++++++--------------------
1 files changed, 28 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index 84a685a5..9a424c4 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -49,7 +49,6 @@ CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_HZ_100=y
CONFIG_BINFMT_MISC=m
-CONFIG_HOTPLUG_CPU=y
CONFIG_KEXEC=y
CONFIG_IRQ_ALL_CPUS=y
CONFIG_MEMORY_HOTREMOVE=y
@@ -75,7 +74,6 @@ CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
-CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_SCTP=m
@@ -133,7 +131,6 @@ CONFIG_NETFILTER_XT_MATCH_U32=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
-CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
@@ -145,7 +142,6 @@ CONFIG_NF_NAT=m
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_REDIRECT=m
-CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
@@ -176,7 +172,6 @@ CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_FC_ATTRS=y
-CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_CXGB4_ISCSI=m
CONFIG_SCSI_BNX2_ISCSI=m
@@ -208,13 +203,6 @@ CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
-CONFIG_IEEE1394=y
-CONFIG_IEEE1394_OHCI1394=y
-CONFIG_IEEE1394_SBP2=m
-CONFIG_IEEE1394_ETH1394=m
-CONFIG_IEEE1394_RAWIO=y
-CONFIG_IEEE1394_VIDEO1394=m
-CONFIG_IEEE1394_DV1394=m
CONFIG_ADB_PMU=y
CONFIG_PMAC_SMU=y
CONFIG_THERM_PM72=y
@@ -223,43 +211,49 @@ CONFIG_WINDFARM_PM81=y
CONFIG_WINDFARM_PM91=y
CONFIG_WINDFARM_PM112=y
CONFIG_WINDFARM_PM121=y
-CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_TUN=m
CONFIG_MARVELL_PHY=y
CONFIG_BROADCOM_PHY=m
-CONFIG_NET_ETHERNET=y
-CONFIG_SUNGEM=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
-CONFIG_IBMVETH=m
-CONFIG_NET_PCI=y
-CONFIG_PCNET32=y
-CONFIG_E100=y
+CONFIG_NET_VENDOR_ALTEON=y
CONFIG_ACENIC=m
CONFIG_ACENIC_OMIT_TIGON_I=y
-CONFIG_E1000=y
-CONFIG_E1000E=y
+CONFIG_NET_VENDOR_AMD=y
+CONFIG_PCNET32=y
CONFIG_TIGON3=y
-CONFIG_BNX2=m
-CONFIG_SPIDER_NET=m
-CONFIG_GELIC_NET=m
-CONFIG_GELIC_WIRELESS=y
CONFIG_CHELSIO_T1=m
-CONFIG_CHELSIO_T3=m
-CONFIG_CHELSIO_T4=m
+CONFIG_NET_VENDOR_EMULEX=y
+CONFIG_BE2NET=m
+CONFIG_NET_VENDOR_EXAR=y
+CONFIG_S2IO=m
+CONFIG_NET_VENDOR_IBM=y
+CONFIG_IBMVETH=m
+CONFIG_ISERIES_VETH=m
CONFIG_EHEA=m
-CONFIG_IXGBE=m
+CONFIG_NET_VENDOR_INTEL=y
+CONFIG_E100=y
+CONFIG_E1000=y
+CONFIG_E1000E=y
CONFIG_IXGB=m
-CONFIG_S2IO=m
+CONFIG_IXGBE=m
+CONFIG_MLX4_EN=m
+CONFIG_NET_VENDOR_MYRI=y
CONFIG_MYRI10GE=m
-CONFIG_NETXEN_NIC=m
+CONFIG_NET_VENDOR_NVIDIA=y
+CONFIG_NET_VENDOR_PASEMI=y
CONFIG_PASEMI_MAC=y
-CONFIG_MLX4_EN=m
+CONFIG_NET_VENDOR_QLOGIC=y
CONFIG_QLGE=m
-CONFIG_BE2NET=m
-CONFIG_ISERIES_VETH=m
+CONFIG_NETXEN_NIC=m
+CONFIG_NET_VENDOR_SUN=y
+CONFIG_SUNGEM=y
+CONFIG_NET_VENDOR_TOSHIBA=y
+CONFIG_GELIC_NET=m
+CONFIG_GELIC_WIRELESS=y
+CONFIG_SPIDER_NET=m
CONFIG_PPP=m
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
@@ -331,7 +325,6 @@ CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_MON=m
CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_EHCI_HCD_PPC_OF is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_STORAGE=m
@@ -373,11 +366,9 @@ CONFIG_JFS_POSIX_ACL=y
CONFIG_JFS_SECURITY=y
CONFIG_XFS_FS=m
CONFIG_XFS_POSIX_ACL=y
-CONFIG_OCFS2_FS=m
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
CONFIG_NILFS2_FS=m
-CONFIG_INOTIFY=y
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_ISO9660_FS=y
@@ -398,7 +389,6 @@ CONFIG_ROOT_NFS=y
CONFIG_NFSD=m
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
-CONFIG_RPCSEC_GSS_SPKM3=m
CONFIG_CIFS=m
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
@@ -444,15 +434,13 @@ CONFIG_CRC_T10DIF=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_LOCKUP_DETECTOR=y
-CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_MUTEXES=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
+CONFIG_DEBUG_STACK_USAGE=y
CONFIG_LATENCYTOP=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_SCHED_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_DEBUG_STACKOVERFLOW=y
-CONFIG_DEBUG_STACK_USAGE=y
CONFIG_CODE_PATCHING_SELFTEST=y
CONFIG_FTR_FIXUP_SELFTEST=y
CONFIG_MSI_BITMAP_SELFTEST=y
@@ -463,10 +451,8 @@ CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
-CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_HMAC=y
-CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
@@ -474,7 +460,6 @@ CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_ANUBIS=m
-CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_KHAZAD=m
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [omega-g1:11072] Re: [PATCH] net: configurable sysctl parameter "net.core.tcp_lowat" for sk_stream_min_wspace()
From: Jun.Kondo @ 2011-08-22 0:33 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, omega-g1, notsuki, motokazu.kozaki, htaira, netdev,
tomohiko.takahashi, kotaro.sakai, ken.sugawara
In-Reply-To: <20110819.024326.598275465899000817.davem@davemloft.net>
By using this patch, we want to prevent "timeout occured over the network that is low throughput but available".
But in the current implementation, both blocking and non-blocking,
user processes can't recognize the reason in detail
when failed to write to socket buffer, we think.
is it (really) network problem ?
or is wmem not enough free to write?
As stated above, we think it is difficult for user processes to handle timeout of writing socket buffer,
when wmem is configured large value.(to ensure high throughput over the high ralency network, like 3G).
(2011/08/19 18:43), David Miller wrote:
> From: "Jun.Kondo"<jun.kondo@ctc-g.co.jp>
> Date: Fri, 19 Aug 2011 18:28:45 +0900
>
>> You suggested to use non-blocking writes, but we think
>> we have to rewrite the Apache code if doing so.
>> That is, we have to make a modification to Apache that
>> depends on the architecture.
>> By using this patch, it can be handled by changing the
>> configuration a little bit on the kernel side for such
>> applications that it is difficult to do so on application
>> side.
> The kernel provides the facilities necessary to achieve your
> goals. It is a userspace problem.
>
--
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
近藤 潤
v 伊藤忠テクノソリューションズ株式会社(CTC)
v システム技術第1部 技術第4課
v 個人:03-6757-2144
v FAX:03-5800-2256
v
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
^ permalink raw reply
* Re: [PATCH 0/2] pktgen: Clone skb to avoid corruption of skbs in ndo_start_xmit methods (v3)
From: Neil Horman @ 2011-08-22 0:27 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1313593637.2776.9.camel@bwh-desktop>
On Wed, Aug 17, 2011 at 04:07:17PM +0100, Ben Hutchings wrote:
> On Tue, 2011-07-26 at 12:05 -0400, Neil Horman wrote:
> > Ok, after considering all your comments, Dave suggested this as an alternate
> > approach:
> >
> > 1) We create a new priv_flag, IFF_SKB_TX_SHARED, to identify drivers capable of
> > handling shared skbs. Default is to not set this flag
> >
> > 2) Modify ether_setup to enable this flag, under the assumption that any driver
> > calling this function is initalizing a real ethernet device and as such can
> > handle shared skbs since they don't tend to store state in the skb struct.
> > Pktgen can then query this flag when a user script attempts to issue the
> > clone_skb command and decide if it is to be alowed or not.
> [...]
>
> A bunch of Ethernet drivers do skb_pad() or skb_padto() in their
> ndo_start_xmit implementations, either to avoid hardware bugs or because
> the MAC doesn't automatically pad to the minimum frame length. This
> presumably means they can't generally handle shared skbs, though in the
> specific case of pktgen it should be safe as long as a single skb is not
> submitted by multiple threads at once.
>
Agreed, given that pktgen is doing skb sharing in a serialized manner (i.e. one
thread of execution increasing skb->users rather than in multiple threads), the
skb_pad[to] cases are safe. Are there cases in which shared skbs are
transmitted in parallel threads that we need to check for?
Neil
> Ben.
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
>
^ permalink raw reply
* Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X
From: Rusty Russell @ 2011-08-22 0:24 UTC (permalink / raw)
To: Michael S. Tsirkin, Sasha Levin; +Cc: linux-kernel, virtualization, netdev, kvm
In-Reply-To: <20110819152335.GA19489@redhat.com>
On Fri, 19 Aug 2011 18:23:35 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Sat, Aug 13, 2011 at 11:51:01AM +0300, Sasha Levin wrote:
> > The MAC of a virtio-net device is located at the first field of the device
> > specific header. This header is located at offset 20 if the device doesn't
> > support MSI-X or offset 24 if it does.
> >
> > Current code in virtnet_probe() used to probe the MAC before checking for
> > MSI-X, which means that the read was always made from offset 20 regardless
> > of whether MSI-X in enabled or not.
> >
> > This patch moves the MAC probe to after the detection of whether MSI-X is
> > enabled. This way the MAC will be read from offset 24 if the device indeed
> > supports MSI-X.
> >
> > Cc: Rusty Russell <rusty@rustcorp.com.au>
> > Cc: Michael S. Tsirkin <mst@redhat.com>
> > Cc: virtualization@lists.linux-foundation.org
> > Cc: netdev@vger.kernel.org
> > Cc: kvm@vger.kernel.org
> > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
>
> I am not sure I see a bug in virtio: the config pace layout simply
> changes as msix is enabled and disabled (and if you look at the latest
> draft, also on whether 64 bit features are enabled).
> It doesn't depend on msix capability being present in device.
>
> The spec seems to be explicit enough:
> If MSI-X is enabled for the device, two additional fields immediately
> follow this header.
>
> So I'm guessing the bug is in kvm tools which assume
> same layout for when msix is enabled and disabled.
> qemu-kvm seems to do the right thing so the device
> seems to get the correct mac.
So, the config space moves once MSI-X is enabled? In which case, it
should say "ONCE MSI-X is enabled..."
Thanks,
Rusty.
^ permalink raw reply
* Re: r8169 hard-freezes the system on big network loads
From: Francois Romieu @ 2011-08-21 22:11 UTC (permalink / raw)
To: Michael Brade; +Cc: netdev, nic_swsd
In-Reply-To: <201108211520.50400.brade@informatik.uni-muenchen.de>
Michael Brade <brade@informatik.uni-muenchen.de> :
[...]
> r8169 0000:13:00.0: eth0: RTL8168d/8111d at 0xffffc90000c72000,
> f0:4d:a2:b8:ce:62, XID 083000c0 IRQ 52
RTL_GIGA_MAC_VER_26
> hope that helps,
Yes. There is enough data for me to reproduce the bug with the
exact same chipset.
--
Ueimor
^ permalink raw reply
* Re: [PATCH][Trivial] net/wan/hdlc_ppp: remove dead goto
From: Jesper Juhl @ 2011-08-21 21:38 UTC (permalink / raw)
To: David Miller; +Cc: khc, netdev, linux-kernel, trivial
In-Reply-To: <20110818.220249.1523360015062657902.davem@davemloft.net>
On Thu, 18 Aug 2011, David Miller wrote:
> From: Jesper Juhl <jj@chaosbits.net>
> Date: Sat, 13 Aug 2011 01:39:43 +0200 (CEST)
>
> > From: Jesper Juhl <jj@chaosbits.net>
> >
> > We'll either hit one of the case labels or the default in the switch
> > and in all cases do we then 'goto out', so having 'goto out' right
> > after the switch is pointless as we can never hit it - remove it.
> >
> > Signed-off-by: Jesper Juhl <jj@chaosbits.net>
>
> Probably a lot cleaner to use break statements in the switch() statement
> and keep this goto in place.
>
> That's more straightforward control flow than what this thing is doing.
Here you are :)
From: Jesper Juhl <jj@chaosbits.net>
Subject: [PATCH] net/wan/hdlc_ppp: use break in switch
We'll either hit one of the case labels or the default in the switch
and in all cases do we then 'goto out' and we also have a 'goto out'
after the switch that is redundant. Change to just use break in the
case statements and leave the 'goto out' after the lop for everyone to
hit.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/net/wan/hdlc_ppp.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wan/hdlc_ppp.c b/drivers/net/wan/hdlc_ppp.c
index 055a918..0d76455 100644
--- a/drivers/net/wan/hdlc_ppp.c
+++ b/drivers/net/wan/hdlc_ppp.c
@@ -515,37 +515,37 @@ static int ppp_rx(struct sk_buff *skb)
switch (cp->code) {
case CP_CONF_REQ:
ppp_cp_parse_cr(dev, pid, cp->id, len, skb->data);
- goto out;
+ break;
case CP_CONF_ACK:
if (cp->id == proto->cr_id)
ppp_cp_event(dev, pid, RCA, 0, 0, 0, NULL);
- goto out;
+ break;
case CP_CONF_REJ:
case CP_CONF_NAK:
if (cp->id == proto->cr_id)
ppp_cp_event(dev, pid, RCN, 0, 0, 0, NULL);
- goto out;
+ break;
case CP_TERM_REQ:
ppp_cp_event(dev, pid, RTR, 0, cp->id, 0, NULL);
- goto out;
+ break;
case CP_TERM_ACK:
ppp_cp_event(dev, pid, RTA, 0, 0, 0, NULL);
- goto out;
+ break;
case CP_CODE_REJ:
ppp_cp_event(dev, pid, RXJ_BAD, 0, 0, 0, NULL);
- goto out;
+ break;
default:
len += sizeof(struct cp_header);
if (len > dev->mtu)
len = dev->mtu;
ppp_cp_event(dev, pid, RUC, 0, 0, len, cp);
- goto out;
+ break;
}
goto out;
--
1.7.6
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH] Documentation: RFC 2553bis is now RFC 3493
From: Geoffrey Thomas @ 2011-08-21 20:13 UTC (permalink / raw)
To: netdev; +Cc: Geoffrey Thomas
Signed-off-by: Geoffrey Thomas <geofft@mit.edu>
---
Documentation/networking/ip-sysctl.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index db2a406..8154699 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -992,7 +992,7 @@ bindv6only - BOOLEAN
TRUE: disable IPv4-mapped address feature
FALSE: enable IPv4-mapped address feature
- Default: FALSE (as specified in RFC2553bis)
+ Default: FALSE (as specified in RFC3493)
IPv6 Fragmentation:
--
1.7.2.5
^ permalink raw reply related
* Re: A question about MTUs and TCP stack
From: Eric Dumazet @ 2011-08-21 20:05 UTC (permalink / raw)
To: Pawan Singh; +Cc: netdev@vger.kernel.org
In-Reply-To: <A55791AD2520D54CA92150D16630D03B36116A5B@VA3DIAXVS1F1.RED001.local>
Le mardi 16 août 2011 à 11:33 -0700, Pawan Singh a écrit :
> Hi
>
> I am posting this question to "netdev" mailing list because I could no
> longer find "linux-net" mailing list.
>
> I find that the Linux TCP stack consumes huge amount of CPU if the MTU
> of an interface is set to 2400 and it is receiving 1000 byte Ethernet
> packets. On the other hand, if the MTU is set to 1500, the CPU
> consumption is reduced drastically. Increased CPU usage causes network
> throughput to drop considerably (from 800-900 Mbps to 200 Mbps). My
> kernel version is fedora core 6 and we are using 1 Gig NICs (Intel
> 82546GB and Broadcom NetXtreme BCM5721):
>
> Linux he7700-tg 2.6.22.14-72.fc6 #1 SMP Wed Nov 21 14:10:25 EST 2007
> x86_64 x86_64 x86_64 GNU/Linux
>
> I do not know the TCP buffer management internals and how they are
> affected by MTU. Is there some FAQ/information online or do I have to
> open up the source code and try to identify the source of the problem.
> I guess I can also try newer versions of the kernel and see if the
> issue has been resolved.
>
I suspect you have a CPU problem on the receiver side, not on transmit
one ?
MTU has a direct impact on skb 'truesize'. As the linux tcp stack takes
care of not using too much kernel ram for the sole use of one socket,
you might hit a per socket limit faster with big MTU (and not filled RX
buffers)
When this limit is hit, tcp stack tries to 'collapse' consecutive skbs
to remove the unused parts of skbs. This is a very expensive process.
With a recent kernel, you could use 'perf top' tool and easily spot the
hot paths in kernel.
^ permalink raw reply
* Re: [OT]Any open source community in wireless network?
From: Randy Dunlap @ 2011-08-21 18:40 UTC (permalink / raw)
To: Sven-Haegar Koch; +Cc: hz hanks, netdev
In-Reply-To: <alpine.DEB.2.02.1108211917440.26263@aurora>
On Sun, 21 Aug 2011 19:20:32 +0200 (CEST) Sven-Haegar Koch wrote:
> On Sun, 21 Aug 2011, hz hanks wrote:
>
> > I am looking for some open source communities in wireless network.
> > This mailing list mainly concentrated on computer networks such as
> > TCP, but my interests are mainly on embedded wireless system and
> > mobile phone system. So is there any kind person could provide me with
> > some open source communities which mainly concentrate on those topics?
> > Thanks a lot.
>
> Like:
> linux-wireless@vger.kernel.org (linux wireless driver development)
> http://www.openwrt.org (embedded linux distribution, for accesspoints
> and more)
> http://www.android.com (smartphone foobar)
http://wireless.kernel.org/ (Linux Wireless wiki)
---
~Randy
^ permalink raw reply
* Re: [OT]Any open source community in wireless network?
From: Sven-Haegar Koch @ 2011-08-21 17:20 UTC (permalink / raw)
To: hz hanks; +Cc: netdev
In-Reply-To: <CAPerbBwowb=5+rOwrf00ZqdmtrtR_39mhvs6jouseOBGz__4Ew@mail.gmail.com>
On Sun, 21 Aug 2011, hz hanks wrote:
> I am looking for some open source communities in wireless network.
> This mailing list mainly concentrated on computer networks such as
> TCP, but my interests are mainly on embedded wireless system and
> mobile phone system. So is there any kind person could provide me with
> some open source communities which mainly concentrate on those topics?
> Thanks a lot.
Like:
linux-wireless@vger.kernel.org (linux wireless driver development)
http://www.openwrt.org (embedded linux distribution, for accesspoints
and more)
http://www.android.com (smartphone foobar)
c'ya
sven-haegar
--
Three may keep a secret, if two of them are dead.
- Ben F.
^ permalink raw reply
* [OT]Any open source community in wireless network?
From: hz hanks @ 2011-08-21 15:49 UTC (permalink / raw)
To: netdev
Hi, all
I am looking for some open source communities in wireless network.
This mailing list mainly concentrated on computer networks such as
TCP, but my interests are mainly on embedded wireless system and
mobile phone system. So is there any kind person could provide me with
some open source communities which mainly concentrate on those topics?
Thanks a lot.
^ permalink raw reply
* Re: [net-next 03/10] ixgbe: Drop the TX work limit and instead just leave it to budget
From: Ben Hutchings @ 2011-08-21 14:01 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Alexander Duyck, netdev, gospo
In-Reply-To: <1313911761-11709-4-git-send-email-jeffrey.t.kirsher@intel.com>
On Sun, 2011-08-21 at 00:29 -0700, Jeff Kirsher wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change makes it so that the TX work limit is now obsolete. Instead of
> using it we can instead rely on the NAPI budget for the number of packets
> we should clean per interrupt. The advantage to this approach is that it
> results in a much more balanced work flow since the same number of RX and
> TX packets should be cleaned per interrupts.
[...]
This seems kind of sensible, but it's not how Dave has been recommending
people to account for TX work in NAPI.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: r8169 hard-freezes the system on big network loads
From: Michael Brade @ 2011-08-21 13:20 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, nic_swsd
In-Reply-To: <20110821123311.GA20605@electric-eye.fr.zoreil.com>
On Sunday 21 August 2011 14:33:11 you wrote:
> (Michael, please don't use the e-mail address of your Solar meditation
> teacher)
Gee...?! that was an accident (and I thought I know what I am doing...)
> > If you need any other information or help, please let me know.
>
> The XID line included in any recent kernel dmesg by the r8169 driver would
> be welcome.
r8169 0000:13:00.0: eth0: RTL8168d/8111d at 0xffffc90000c72000,
f0:4d:a2:b8:ce:62, XID 083000c0 IRQ 52
hope that helps,
Michael
^ permalink raw reply
* Re: r8169 hard-freezes the system on big network loads
From: Francois Romieu @ 2011-08-21 12:33 UTC (permalink / raw)
To: Kjun Chen; +Cc: netdev, nic_swsd, Michael Brade
In-Reply-To: <201108141308.28140.kjun-chen@sambodha.org>
(Michael, please don't use the e-mail address of your Solar meditation teacher)
Kjun Chen <kjun-chen@sambodha.org> :
[...]
> If you need any other information or help, please let me know.
The XID line included in any recent kernel dmesg by the r8169 driver would
be welcome.
Thanks.
--
Ueimor
^ permalink raw reply
* Re: Bridge stays down until a port is added
From: Marc Haber @ 2011-08-21 12:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Sven-Haegar Koch
In-Reply-To: <20110820093059.75c37a1f@nehalam.ftrdhcpuser.net>
On Sat, Aug 20, 2011 at 09:30:59AM -0700, Stephen Hemminger wrote:
> The problem is that IPv6 Duplicate Address Detection needs to
> work. This is not a simple problem. If the bridge asserted
> carrier with no ports then:
>
> 1. IPv6 address assigned and IPv6 decides it is okay.
> 2. Port added later
> 3. Another system has the same address.
> *broke*
Same situation when a system-to-system-link is added after bringing up
an interface. I agree that the issue is not an issue if a real switch
is being used.
> If you want to avoid DAD, then you can configure disable DAD
> by setting /proc/sys/net/ipv6/conf/br0/accept_dad to 0
I'd like to avoid that.
2001:db8::1
Would it acceptable (and clean!) to have:
eth0: 2001:db8:1::100/64 default gw to the internet is 2001:db8:1::1
lo: 127.0.0.1/8, ::1/128, 2001:db8:2::100/64
br0: 2001:db8:2::1/64 (being default gw for the VMs connected to br0,
routing 2001:db8:2::/64 to the Internet)
Note 2001:db8:2::/64 being used both on lo and br0, with 2001:db8:2::100 meant
to be reachable from the Internet even if no VM is already up. my
hostname will be A-Recorded to 2001:db8:2::100 with proper reverse
DNS. The background for doing so is that I cannot control the reverse
DNS for the IP addresses inside 200a:db8:1::/64 in a lot of my setups
(for example, if my IPv6 comes in via Sixxs).
Is this going to work in a clean way?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
^ permalink raw reply
* Re: strange routing issue--packets stop getting forwarded for a live connection
From: Julian Anastasov @ 2011-08-21 9:02 UTC (permalink / raw)
To: Corey Hickey; +Cc: Linux Netdev List
In-Reply-To: <4E50BDFB.7050502@fatooh.org>
Hello,
On Sun, 21 Aug 2011, Corey Hickey wrote:
> >> 3. MTU size; 1500 on eth0 and 1406 on tun0. Bigger packets have been
> >> transferred fine.
> >
> > Lower MTU, it can be PMTUD problem. At 04:50:24.112658
> > I see 7801:9169 is 1420 bytes and no ICMP FRAG NEEDED is generated.
> > May be these two regressions explain it:
> >
> > http://marc.info/?l=linux-netdev&m=131342172722536&w=2
> >
> > There are 2 fixes you can try or more recent kernel
> > tree, for example 3.1-rc2 has the fixes.
>
> Many thanks for your reply--it looks like you're on to something. You
> didn't specify which interface to lower the MTU on, so I tried them each
> in turn, and found that lowering the MTU on the client machine to 1406
> (matching tun0 on the router) did indeed solve the problem. That makes
> sense in retrospect.
I just wanted to note the difference in MTUs
as a possible cause that triggers the problem. And after
your confirmation I think the new/patched kernel should work
without playing with MTUs.
> It's a bit late at night for me to be patching my kernel, but I'll see
> if I can do it tomorrow.
>
> Thanks again, and I'll let you know how it turns out.
>
> -Corey
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH] net: add APIs for manipulating skb page fragments.
From: Ian Campbell @ 2011-08-21 8:23 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
eric.dumazet@gmail.com, mirq-linux@rere.qmqm.pl
In-Reply-To: <20110820.173133.1612902138924735868.davem@davemloft.net>
On Sun, 2011-08-21 at 01:31 +0100, David Miller wrote:
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Fri, 19 Aug 2011 17:25:00 +0100
>
> > The primary aim is to add skb_frag_(ref|unref) in order to remove the use of
> > bare get/put_page on SKB pages fragments and to isolate users from subsequent
> > changes to the skb_frag_t data structure.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
> You're going to have to protect all of the things using the interfaces
> from linux/dma-mapping.h with CONFIG_HAS_DMA otherwise it won't build
> on platforms like S390.
s390 is one of the arches which I build tested and I initially saw this
issue too. I did add CONFIG_HAS_DMA but it turns out that
linux/dma-mapping.h takes care of this by including
asm-generic/dma-mapping-broken.h for you so I removed the #ifdef again.
The header defines the prototypes to allow building but causes a link
time failure if anything actually uses the interfaces.
I just tested a s390x defconfig build again and it appears to be fine.
Ian.
^ permalink raw reply
* Re: strange routing issue--packets stop getting forwarded for a live connection
From: Corey Hickey @ 2011-08-21 8:12 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Linux Netdev List
In-Reply-To: <alpine.LFD.2.00.1108210924010.1581@ja.ssi.bg>
On 2011-08-20 23:35, Julian Anastasov wrote:
>> I have a strange issue where, reliably, certain conditions cause my
>> Linux router to stop forwarding packets for a connection.
[...]
>> 3. MTU size; 1500 on eth0 and 1406 on tun0. Bigger packets have been
>> transferred fine.
>
> Lower MTU, it can be PMTUD problem. At 04:50:24.112658
> I see 7801:9169 is 1420 bytes and no ICMP FRAG NEEDED is generated.
> May be these two regressions explain it:
>
> http://marc.info/?l=linux-netdev&m=131342172722536&w=2
>
> There are 2 fixes you can try or more recent kernel
> tree, for example 3.1-rc2 has the fixes.
Many thanks for your reply--it looks like you're on to something. You
didn't specify which interface to lower the MTU on, so I tried them each
in turn, and found that lowering the MTU on the client machine to 1406
(matching tun0 on the router) did indeed solve the problem. That makes
sense in retrospect.
It's a bit late at night for me to be patching my kernel, but I'll see
if I can do it tomorrow.
Thanks again, and I'll let you know how it turns out.
-Corey
^ permalink raw reply
* Nine Hundred And Fifty Thousand Pounds Was Awarded To Your ID In The Benz Cash Offer, Get Bact To Us With Your:
From: letrevino @ 2011-08-21 6:32 UTC (permalink / raw)
1. Full Name:
2. Full Address:
3. Phone number:
4. Country:
^ 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