* [PATCH 2/7] tcp_cubic: fix comparison of jiffies
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-cubic-jiffies-wrap.patch --]
[-- Type: text/plain, Size: 1021 bytes --]
Jiffies wraps around therefore the correct way to compare is
to use cast to signed value.
Note: cubic is not using full jiffies value on 64 bit arch
because using full unsigned long makes struct bictcp grow too
large for the available ca_priv area.
Includes correction from Sangtae Ha to improve ack train detection.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/ipv4/tcp_cubic.c 2011-03-11 09:00:06.856664687 -0800
+++ b/net/ipv4/tcp_cubic.c 2011-03-11 09:02:11.685796371 -0800
@@ -342,9 +342,11 @@ static void hystart_update(struct sock *
u32 curr_jiffies = jiffies;
/* first detection parameter - ack-train detection */
- if (curr_jiffies - ca->last_jiffies <= msecs_to_jiffies(2)) {
+ if ((s32)(curr_jiffies - ca->last_jiffies) <=
+ msecs_to_jiffies(2)) {
ca->last_jiffies = curr_jiffies;
- if (curr_jiffies - ca->round_start >= ca->delay_min>>4)
+ if ((s32) (curr_jiffies - ca->round_start) >
+ ca->delay_min >> 4)
ca->found |= HYSTART_ACK_TRAIN;
}
^ permalink raw reply
* [PATCH 1/7] tcp: fix RTT for quick packets in congestion control
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-input-rtt.patch --]
[-- Type: text/plain, Size: 967 bytes --]
In the congestion control interface, the callback for each ACK
includes an estimated round trip time in microseconds.
Some algorithms need high resolution (Vegas style) but most only
need jiffie resolution. If RTT is not accurate (like a retransmission)
-1 is used as a flag value.
When doing coarse resolution if RTT is less than a a jiffie
then 0 should be returned rather than no estimate. Otherwise algorithms
that expect good ack's to trigger slow start (like CUBIC Hystart)
will be confused.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/ipv4/tcp_input.c 2011-03-14 08:31:35.442834792 -0700
+++ b/net/ipv4/tcp_input.c 2011-03-14 08:31:40.078917049 -0700
@@ -3350,7 +3350,7 @@ static int tcp_clean_rtx_queue(struct so
net_invalid_timestamp()))
rtt_us = ktime_us_delta(ktime_get_real(),
last_ackt);
- else if (ca_seq_rtt > 0)
+ else if (ca_seq_rtt >= 0)
rtt_us = jiffies_to_usecs(ca_seq_rtt);
}
^ permalink raw reply
* [PATCH 4/7] tcp_cubic: fix clock dependency
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-cubic-minrtt.patch --]
[-- Type: text/plain, Size: 2977 bytes --]
The hystart code was written with assumption that HZ=1000.
Replace the use of jiffies with bictcp_clock as a millisecond
real time clock.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Reported-by: Lucas Nussbaum <lucas.nussbaum@loria.fr>
--- a/net/ipv4/tcp_cubic.c 2011-03-14 08:19:18.000000000 -0700
+++ b/net/ipv4/tcp_cubic.c 2011-03-14 08:22:42.486690594 -0700
@@ -88,7 +88,7 @@ struct bictcp {
u32 last_time; /* time when updated last_cwnd */
u32 bic_origin_point;/* origin point of bic function */
u32 bic_K; /* time to origin point from the beginning of the current epoch */
- u32 delay_min; /* min delay */
+ u32 delay_min; /* min delay (msec << 3) */
u32 epoch_start; /* beginning of an epoch */
u32 ack_cnt; /* number of acks */
u32 tcp_cwnd; /* estimated tcp cwnd */
@@ -98,7 +98,7 @@ struct bictcp {
u8 found; /* the exit point is found? */
u32 round_start; /* beginning of each round */
u32 end_seq; /* end_seq of the round */
- u32 last_jiffies; /* last time when the ACK spacing is close */
+ u32 last_ack; /* last time when the ACK spacing is close */
u32 curr_rtt; /* the minimum rtt of current round */
};
@@ -119,12 +119,21 @@ static inline void bictcp_reset(struct b
ca->found = 0;
}
+static inline u32 bictcp_clock(void)
+{
+#if HZ < 1000
+ return ktime_to_ms(ktime_get_real());
+#else
+ return jiffies_to_msecs(jiffies);
+#endif
+}
+
static inline void bictcp_hystart_reset(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
struct bictcp *ca = inet_csk_ca(sk);
- ca->round_start = ca->last_jiffies = jiffies;
+ ca->round_start = ca->last_ack = bictcp_clock();
ca->end_seq = tp->snd_nxt;
ca->curr_rtt = 0;
ca->sample_cnt = 0;
@@ -239,8 +248,8 @@ static inline void bictcp_update(struct
*/
/* change the unit from HZ to bictcp_HZ */
- t = ((tcp_time_stamp + (ca->delay_min>>3) - ca->epoch_start)
- << BICTCP_HZ) / HZ;
+ t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3)
+ - ca->epoch_start) << BICTCP_HZ) / HZ;
if (t < ca->bic_K) /* t - K */
offs = ca->bic_K - t;
@@ -342,14 +351,12 @@ static void hystart_update(struct sock *
struct bictcp *ca = inet_csk_ca(sk);
if (!(ca->found & hystart_detect)) {
- u32 curr_jiffies = jiffies;
+ u32 now = bictcp_clock();
/* first detection parameter - ack-train detection */
- if ((s32)(curr_jiffies - ca->last_jiffies) <=
- msecs_to_jiffies(hystart_ack_delta)) {
- ca->last_jiffies = curr_jiffies;
- if ((s32) (curr_jiffies - ca->round_start) >
- ca->delay_min >> 4)
+ if ((s32)(now - ca->last_ack) <= hystart_ack_delta) {
+ ca->last_ack = now;
+ if ((s32)(now - ca->round_start) > ca->delay_min >> 4)
ca->found |= HYSTART_ACK_TRAIN;
}
@@ -396,7 +403,7 @@ static void bictcp_acked(struct sock *sk
if ((s32)(tcp_time_stamp - ca->epoch_start) < HZ)
return;
- delay = usecs_to_jiffies(rtt_us) << 3;
+ delay = (rtt_us << 3) / USEC_PER_MSEC;
if (delay == 0)
delay = 1;
^ permalink raw reply
* [PATCH 3/7] tcp_cubic: make ack train delta value a parameter
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-cubic-ackdelta.patch --]
[-- Type: text/plain, Size: 1432 bytes --]
Make the spacing between ACK's that indicates a train a tuneable
value like other hystart values.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/ipv4/tcp_cubic.c 2011-03-14 08:19:15.697936023 -0700
+++ b/net/ipv4/tcp_cubic.c 2011-03-14 08:19:18.361944814 -0700
@@ -52,6 +52,7 @@ static int tcp_friendliness __read_mostl
static int hystart __read_mostly = 1;
static int hystart_detect __read_mostly = HYSTART_ACK_TRAIN | HYSTART_DELAY;
static int hystart_low_window __read_mostly = 16;
+static int hystart_ack_delta __read_mostly = 2;
static u32 cube_rtt_scale __read_mostly;
static u32 beta_scale __read_mostly;
@@ -75,6 +76,8 @@ MODULE_PARM_DESC(hystart_detect, "hyrbri
" 1: packet-train 2: delay 3: both packet-train and delay");
module_param(hystart_low_window, int, 0644);
MODULE_PARM_DESC(hystart_low_window, "lower bound cwnd for hybrid slow start");
+module_param(hystart_ack_delta, int, 0644);
+MODULE_PARM_DESC(hystart_ack_delta, "spacing between ack's indicating train (msecs)");
/* BIC TCP Parameters */
struct bictcp {
@@ -343,7 +346,7 @@ static void hystart_update(struct sock *
/* first detection parameter - ack-train detection */
if ((s32)(curr_jiffies - ca->last_jiffies) <=
- msecs_to_jiffies(2)) {
+ msecs_to_jiffies(hystart_ack_delta)) {
ca->last_jiffies = curr_jiffies;
if ((s32) (curr_jiffies - ca->round_start) >
ca->delay_min >> 4)
^ permalink raw reply
* [PATCH 0/7] TCP CUBIC Hystart fixes
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
This is the merge of my patches and recent update Sangtae.
It addresses the problems reported by Lucas Nussbaum that Hystart causes
poor startup performance over links with lots of buffering.
^ permalink raw reply
* [PATCH 5/7] tcp_cubic: enable high resolution ack time if needed
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-cubic-rtt-cong.patch --]
[-- Type: text/plain, Size: 726 bytes --]
This is a refined version of an earlier patch by Lucas Nussbaum.
Cubic needs RTT values in milliseconds. If HZ < 1000 then
the values will be too coarse.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Reported-by: Lucas Nussbaum <lucas.nussbaum@loria.fr>
--- a/net/ipv4/tcp_cubic.c 2011-03-14 08:22:42.486690594 -0700
+++ b/net/ipv4/tcp_cubic.c 2011-03-14 08:27:24.435852847 -0700
@@ -459,6 +459,10 @@ static int __init cubictcp_register(void
/* divide by bic_scale and by constant Srtt (100ms) */
do_div(cube_factor, bic_scale * 10);
+ /* hystart needs ms clock resolution */
+ if (hystart && HZ < 1000)
+ cubictcp.flags |= TCP_CONG_RTT_STAMP;
+
return tcp_register_congestion_control(&cubictcp);
}
^ permalink raw reply
* [PATCH 7/7] tcp_cubic: fix low utilization of CUBIC with HyStart
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Sangtae Ha
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-cubic-initial-growth.patch --]
[-- Type: text/plain, Size: 1077 bytes --]
From: Sangtae Ha <sangtae.ha@gmail.com>
HyStart sets the initial exit point of slow start.
Suppose that HyStart exits at 0.5BDP in a BDP network and no history exists.
If the BDP of a network is large, CUBIC's initial cwnd growth may be
too conservative to utilize the link.
CUBIC increases the cwnd 20% per RTT in this case.
Signed-off-by: Sangtae Ha <sangtae.ha@gmail.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
---
net/ipv4/tcp_cubic.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
--- a/net/ipv4/tcp_cubic.c 2011-03-14 08:32:46.347993869 -0700
+++ b/net/ipv4/tcp_cubic.c 2011-03-14 10:57:00.846549449 -0700
@@ -270,6 +270,13 @@ static inline void bictcp_update(struct
ca->cnt = 100 * cwnd; /* very small increment*/
}
+ /*
+ * The initial growth of cubic function may be too conservative
+ * when the available bandwidth is still unknown.
+ */
+ if (ca->loss_cwnd == 0 && ca->cnt > 20)
+ ca->cnt = 20; /* increase cwnd 5% per RTT */
+
/* TCP Friendly */
if (tcp_friendliness) {
u32 scale = beta_scale;
^ permalink raw reply
* [PATCH 6/7] tcp_cubic: make the delay threshold of HyStart less sensitive
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Sangtae Ha
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-cubic-increase-delay.patch --]
[-- Type: text/plain, Size: 795 bytes --]
From: Sangtae Ha <sangtae.ha@gmail.com>
Make HyStart less sensitive to abrupt delay variations due to buffer bloat.
Signed-off-by: Sangtae Ha <sangtae.ha@gmail.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Reported-by: Lucas Nussbaum <lucas.nussbaum@loria.fr>
---
net/ipv4/tcp_cubic.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--- a/net/ipv4/tcp_cubic.c 2011-03-14 08:27:24.435852847 -0700
+++ b/net/ipv4/tcp_cubic.c 2011-03-14 08:27:29.043872578 -0700
@@ -39,7 +39,7 @@
/* Number of delay samples for detecting the increase of delay */
#define HYSTART_MIN_SAMPLES 8
-#define HYSTART_DELAY_MIN (2U<<3)
+#define HYSTART_DELAY_MIN (4U<<3)
#define HYSTART_DELAY_MAX (16U<<3)
#define HYSTART_DELAY_THRESH(x) clamp(x, HYSTART_DELAY_MIN, HYSTART_DELAY_MAX)
^ permalink raw reply
* Re: how to utilize multi tx queue to sent packets
From: Stephen Hemminger @ 2011-03-14 18:14 UTC (permalink / raw)
To: Jon Zhou; +Cc: netdev@vger.kernel.org
In-Reply-To: <4A6A2125329CFD4D8CC40C9E8ABCAB9F24FB47E9EE@MILEXCH2.ds.jdsu.net>
On Sun, 13 Mar 2011 01:06:11 -0800
Jon Zhou <Jon.Zhou@jdsu.com> wrote:
>
>
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> > Sent: Saturday, March 12, 2011 1:07 AM
> > To: Jon Zhou
> > Cc: netdev@vger.kernel.org
> > Subject: Re: how to utilize multi tx queue to sent packets
> >
> > On Thu, 10 Mar 2011 22:52:30 -0800
> > Jon Zhou <Jon.Zhou@jdsu.com> wrote:
> >
> > > hi
> > >
> > > I am doing some test according to the
> > > website:http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap
> > >
> > > use packet_mmap tx_ring to send packet.
> > >
> > > I modified the sample code "packetmmap.c" to make it send packets
> > have different outer ip.
> > > so that with the help of RSS, I can achieve higher throughput.
> > >
> > > but one thing I saw at the tx side, is that all the packets are sent
> > via the same tx_queue,
> > > which is conflict with what I saw at the rx side.
> > > any idea to make it sent packets via different tx_queues? (spread
> > across the tx_queues)
> >
> > You need to have multiple threads to get Tx scaling.
> > In you case that also means multiple AF_PACKET sockets and separate
> > rings.
> >
> > Or just run multiple copies of the same test each with a different IP
>
> How does kernel know which tx_queue to use?
> Will dev_queue_xmit determine tx_queue(sw queue) to send packets?
> Or just let NIC select a tx_queue(hardware) ?
>
On most hardware, with multi-queue there is one queue per CPU.
In that case the queue selected corresponds to the CPU.
--
^ permalink raw reply
* Re: [GIT PULL nf-next-2.6] IPVS
From: Patrick McHardy @ 2011-03-14 18:17 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Hans Schillstrom,
Julian Anastasov
In-Reply-To: <1300056261-14709-1-git-send-email-horms@verge.net.au>
On 13.03.2011 23:44, Simon Horman wrote:
> Hi Patrick,
>
> please consider pulling
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git master
> to get the following changes.
>
> Jesper Juhl (1):
> Fix variable assignment in ip_vs_notrack
>
> Julian Anastasov (2):
> ipvs: avoid lookup for fwmark 0
> ipvs: remove _bh from percpu stats reading
>
> Shan Wei (1):
> netfilter:ipvs: use kmemdup
>
> include/net/ip_vs.h | 2 +-
> net/netfilter/ipvs/ip_vs_ctl.c | 8 +++++---
> net/netfilter/ipvs/ip_vs_est.c | 8 ++++----
> net/netfilter/ipvs/ip_vs_pe_sip.c | 9 ++++-----
> net/netfilter/ipvs/ip_vs_sync.c | 3 +--
> 5 files changed, 15 insertions(+), 15 deletions(-)
The pull contained quite a lot of other changes. I'm undoing the
pull for now, please resubmit the patches you actually want me to
pull. Thanks!
Jesper Juhl (1):
Fix variable assignment in ip_vs_notrack
Julian Anastasov (8):
ipvs: avoid lookup for fwmark 0
ipvs: remove _bh from percpu stats reading
ipvs: move struct netns_ipvs
ipvs: reorganize tot_stats
ipvs: properly zero stats and rates
ipvs: remove unused seqcount stats
ipvs: optimize rates reading
ipvs: rename estimator functions
Patrick McHardy (1):
Merge branch 'master' of git://git.kernel.org/.../horms/lvs-test-2.6
Shan Wei (1):
netfilter:ipvs: use kmemdup
Simon Horman (14):
IPVS: Add ip_vs_route_me_harder()
IPVS: Add sysctl_snat_reroute()
IPVS: Add sysctl_nat_icmp_send()
IPVS: Add {sysctl_sync_threshold,period}()
IPVS: Add sysctl_sync_ver()
IPVS: Add sysctl_expire_nodest_conn()
IPVS: Add expire_quiescent_template()
IPVS: Conditinally use sysctl_lblc{r}_expiration
IPVS: ip_vs_todrop() becomes a noop when CONFIG_SYSCTL is undefined
IPVS: Conditional ip_vs_conntrack_enabled()
IPVS: Minimise ip_vs_leave when CONFIG_SYSCTL is undefined
IPVS: Conditionally define and use ip_vs_lblc{r}_table
IPVS: Add __ip_vs_control_{init,cleanup}_sysctl()
IPVS: Conditionally include sysctl members of struct netns_ipvs
^ permalink raw reply
* Re: [PATCH] conntrack: fix sysctl memory leak
From: Patrick McHardy @ 2011-03-14 18:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, netdev, netfilter-devel
In-Reply-To: <20110310101422.62006620@nehalam>
On 10.03.2011 19:14, Stephen Hemminger wrote:
> Message in log because sysctl table was not empty at netns exit
> WARNING: at net/sysctl_net.c:84 sysctl_net_exit+0x2a/0x2c()
>
> Instrumenting showed that the nf_conntrack_timestamp was the entry
> that was being created but not cleared.
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH 1/4] netfilter: xt_connlimit: fix daddr connlimit in SNAT scenario
From: Patrick McHardy @ 2011-03-14 18:32 UTC (permalink / raw)
To: Changli Gao; +Cc: Jan Engelhardt, David S. Miller, netfilter-devel, netdev
In-Reply-To: <AANLkTi=QgVBVAPcTmb_La=VJOLq5LmGPqMfw7bbCuByP@mail.gmail.com>
On 14.03.2011 13:42, Changli Gao wrote:
> On Mon, Mar 14, 2011 at 8:26 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>> On Monday 2011-03-14 07:50, Changli Gao wrote:
>>
>>> We use the reply tuples when limiting the connections by the destination
>>> addresses, however, in SNAT scenario, the final reply tuples won't be
>>> ready until SNAT is done in POSTROUING or INPUT chain
>>
>> If I am not mistaken: if you do daddr counting, SNAT is irrelevant.
>> Consider ruleset
>> -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 1.2.3.4:80
>> -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to 1.2.3.5:443
>>
>> The tuple will first be (as per conntrack -L):
>> src=home dst=router src=router dst=home
>> After DNAT:
>> src=home dst=router src=1.2.3.4 dst=home
>>
>> Thus looking at the src of the reply tuple seems correct — at least this
>> is what was wanted, counting per stashed servers (=1 customer), not per
>> globally visible address.
>>
>
> Yes, you are correct only when there is no SNAT rule. If there is an SNAT rule:
>
> -t nat -A POSTROUTING -p tcp --dport 80 -j SNAT --to-source 192.168.0.1
>
> the final tuples will be:
> src = home dst = router src=1.2.3.4 dst=192.168.0.1
>
> However, the tuple saved by connlimit is src=1.2.3.4 dst=home, so this
> conn will be removed later as there isn't any conntrack, which has
> this tuple in any direction.
>
> You can't prevent a user from doing such a configuration, although you
> might think it is stupid to do that.
>
> Thanks for your review.
Jan, please let me know whether you want me to apply these patches.
Thanks.
^ permalink raw reply
* Re: [GIT/PATCH v5] xen network backend driver
From: Ben Hutchings @ 2011-03-14 18:40 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev@vger.kernel.org, xen-devel, Jeremy Fitzhardinge,
Herbert Xu, Konrad Rzeszutek Wilk, Francois Romieu,
Stephen Hemminger, Michał Mirosław
In-Reply-To: <1300112879.17339.2162.camel@zakaz.uk.xensource.com>
On Mon, 2011-03-14 at 14:27 +0000, Ian Campbell wrote:
> The following patch is the fifth iteration of the Xen network backend
> driver for upstream Linux.
>
> This driver ("netback") is the host side counterpart to the frontend
> driver in drivers/net/xen-netfront.c. The PV protocol is also
> implemented by frontend drivers in other OSes too, such as the BSDs and
> even Windows.
>
> Changes since the fourth posting, due to review from Stephen Hemminger:
> * Treat dev->features as u32 (it effectively is already and
> becomes literally so in net-next -- there's no harm in netback
> switching earlier)
> * Use stats from struct netdevice instead of a local copy.
[...]
All looks good (or good enough) to me. I would add Reviewed-by, but
this isn't a single patch.
I know you have asked for this to be pulled, in order to retain its
history, but I'm not sure that David Miller will do this unless the
driver is at least buildable at each stage in the history. (However,
given that the driver wouldn't be enabled before it's added, I'm not
sure it matters in this case.)
Ben.
--
Ben Hutchings, Senior Software 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 4/7] tcp_cubic: fix clock dependency
From: Eric Dumazet @ 2011-03-14 18:51 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, netdev
In-Reply-To: <20110314175439.564307922@vyatta.com>
Le lundi 14 mars 2011 à 10:52 -0700, Stephen Hemminger a écrit :
> pièce jointe document texte brut (tcp-cubic-minrtt.patch)
> The hystart code was written with assumption that HZ=1000.
> Replace the use of jiffies with bictcp_clock as a millisecond
> real time clock.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> Reported-by: Lucas Nussbaum <lucas.nussbaum@loria.fr>
>
> --- a/net/ipv4/tcp_cubic.c 2011-03-14 08:19:18.000000000 -0700
> +++ b/net/ipv4/tcp_cubic.c 2011-03-14 08:22:42.486690594 -0700
> @@ -88,7 +88,7 @@ struct bictcp {
> u32 last_time; /* time when updated last_cwnd */
> u32 bic_origin_point;/* origin point of bic function */
> u32 bic_K; /* time to origin point from the beginning of the current epoch */
> - u32 delay_min; /* min delay */
> + u32 delay_min; /* min delay (msec << 3) */
> u32 epoch_start; /* beginning of an epoch */
> u32 ack_cnt; /* number of acks */
> u32 tcp_cwnd; /* estimated tcp cwnd */
> @@ -98,7 +98,7 @@ struct bictcp {
> u8 found; /* the exit point is found? */
> u32 round_start; /* beginning of each round */
> u32 end_seq; /* end_seq of the round */
> - u32 last_jiffies; /* last time when the ACK spacing is close */
> + u32 last_ack; /* last time when the ACK spacing is close */
> u32 curr_rtt; /* the minimum rtt of current round */
> };
>
> @@ -119,12 +119,21 @@ static inline void bictcp_reset(struct b
> ca->found = 0;
> }
>
> +static inline u32 bictcp_clock(void)
> +{
> +#if HZ < 1000
> + return ktime_to_ms(ktime_get_real());
Small point : This can be changed if date/time is changed
Maybe use monotonic time (aka ktime_get_ts()) ?
^ permalink raw reply
* Re: [PATCH 1/4] netfilter: xt_connlimit: fix daddr connlimit in SNAT scenario
From: Jan Engelhardt @ 2011-03-14 19:00 UTC (permalink / raw)
To: Changli Gao; +Cc: Patrick McHardy, David S. Miller, netfilter-devel, netdev
In-Reply-To: <AANLkTi=QgVBVAPcTmb_La=VJOLq5LmGPqMfw7bbCuByP@mail.gmail.com>
On Monday 2011-03-14 13:42, Changli Gao wrote:
>On Mon, Mar 14, 2011 at 8:26 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>> On Monday 2011-03-14 07:50, Changli Gao wrote:
>>
>>>We use the reply tuples when limiting the connections by the destination
>>>addresses, however, in SNAT scenario, the final reply tuples won't be
>>>ready until SNAT is done in POSTROUING or INPUT chain
>>
>> If I am not mistaken: if you do daddr counting, SNAT is irrelevant.
>> Consider ruleset
>> -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 1.2.3.4:80
>> -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to 1.2.3.5:443
>>
>> The tuple will first be (as per conntrack -L):
>> src=home dst=router src=router dst=home
>> After DNAT:
>> src=home dst=router src=1.2.3.4 dst=home
>>
>> Thus looking at the src of the reply tuple seems correct — at least this
>> is what was wanted, counting per stashed servers (=1 customer), not per
>> globally visible address.
>>
>
>Yes, you are correct only when there is no SNAT rule. If there is an
>SNAT rule:
>
>-t nat -A POSTROUTING -p tcp --dport 80 -j SNAT --to-source 192.168.0.1
>
>the final tuples will be:
>src = home dst = router src=1.2.3.4 dst=192.168.0.1
>
>However, the tuple saved by connlimit is src=1.2.3.4 dst=home, so this
>conn will be removed later as there isn't any conntrack, which has
>this tuple in any direction.
But I don't yet see how your patch #1 can help. At the time
conn->tuple = *tuple is done, *tuple still contains the non-SNATed
tuple, and it is never updated again.
(Patrick: patches 2-4 are ok)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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 2/2] dev : fix mtu check when TSO is enabled
From: Daniel Lezcano @ 2011-03-14 19:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kaber, nightnord, netdev
In-Reply-To: <1300122105.3423.131.camel@edumazet-laptop>
On 03/14/2011 06:01 PM, Eric Dumazet wrote:
> Le lundi 14 mars 2011 à 17:08 +0100, Daniel Lezcano a écrit :
>> In case the device where is coming from the packet has TSO enabled,
>> we should not check the mtu size value as this one could be bigger
>> than the expected value.
>>
>> This is the case for the macvlan driver when the lower device has
>> TSO enabled. The macvlan inherit this feature and forward the packets
>> without fragmenting them. Then the packets go through dev_forward_skb
>> and are dropped. This patch fix this by checking TSO is not enabled
>> when we want to check the mtu size.
>>
>> Signed-off-by: Daniel Lezcano<daniel.lezcano@free.fr>
>> Cc: Patrick McHardy<kaber@trash.net>
>> Cc: Andrian Nord<nightnord@gmail.com>
>> ---
>> net/core/dev.c | 6 ++++--
>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 6561021..010a0a9 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -1526,8 +1526,10 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
>> skb_orphan(skb);
>> nf_reset(skb);
>>
>> - if (unlikely(!(dev->flags& IFF_UP) ||
>> - (skb->len> (dev->mtu + dev->hard_header_len + VLAN_HLEN)))) {
>> + if (unlikely(!(skb->dev->features& NETIF_F_TSO)&&
>
> Sorry, this needs a comment at least, or even better a helper function
> on its own.
>
> We test both skb->dev& dev, pointing to different devices, this is
> really error prone.
>
> Are we sure all callers set skb->dev before calling dev_forward_skb() ?
Thanks Eric for the comments, I will resend a new version.
-- Daniel
^ permalink raw reply
* Re: fcoe: correct checking for bonding
From: Robert Love @ 2011-03-14 19:04 UTC (permalink / raw)
To: David Miller
Cc: jpirko@redhat.com, James.Bottomley@suse.de,
linux-scsi@vger.kernel.org, devel@open-fcoe.org,
netdev@vger.kernel.org, fubar@us.ibm.com, joe.eykholt@gmail.com
In-Reply-To: <20110312.105944.193725929.davem@davemloft.net>
On Sat, 2011-03-12 at 10:59 -0800, David Miller wrote:
> From: Jiri Pirko <jpirko@redhat.com>
> Date: Sat, 12 Mar 2011 13:01:10 +0100
>
> > Thu, Mar 03, 2011 at 02:09:18AM CET, robert.w.love@intel.com wrote:
> >>On Wed, 2011-03-02 at 01:55 -0800, Jiri Pirko wrote:
> >>> Or perhaps this should be applied to net-next?
> >>>
> >>I think this should go through scsi-misc as all the other
> >>libfc/libfcoe/fcoe patches do.
> >>
> >>> Wed, Mar 02, 2011 at 07:05:35AM CET, jpirko@redhat.com wrote:
> >>> >Check for bonding master and refuse to use that.
> >>> >
> >>> >Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> >>> >---
> >>> > drivers/scsi/fcoe/fcoe.c | 4 +---
> >>> > 1 files changed, 1 insertions(+), 3 deletions(-)
> >>> >
> >>> >diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
> >>> >index 9f9600b..3becc6a 100644
> >>> >--- a/drivers/scsi/fcoe/fcoe.c
> >>> >+++ b/drivers/scsi/fcoe/fcoe.c
> >>> >@@ -285,9 +285,7 @@ static int fcoe_interface_setup(struct fcoe_interface *fcoe,
> >>> > }
> >>> >
> >>> > /* Do not support for bonding device */
> >>> >- if ((netdev->priv_flags & IFF_MASTER_ALB) ||
> >>> >- (netdev->priv_flags & IFF_SLAVE_INACTIVE) ||
> >>> >- (netdev->priv_flags & IFF_MASTER_8023AD)) {
> >>> >+ if (netdev->priv_flags & IFF_BONDING && netdev->flags & IFF_MASTER) {
> >>> > FCOE_NETDEV_DBG(netdev, "Bonded interfaces not supported\n");
> >>> > return -EOPNOTSUPP;
> >>> > }
> >>> >--
> >>> >1.7.3.4
> >>> >
> >>
> >>James, feel free to pick up this patch. I don't have anything in my fcoe
> >>tree right now that it would conflict with. I'll also put it in my tree
> >>and resend if you don't put it into scsi-misc directly.
> >
> > What's the status of this? Maybe this should rather go thru net-next
>
> Sure, I can take this. I'll look at it later.
Hi Dave,
I'd rather have this patch go through scsi-misc. Most, if not all,
libfc, libfcoe and fcoe patches have taken this path. The way it has
been working is that I have been collecting fcoe patches and re-posting
them to scsi-misc after I have reviewed them and done some basic
testing.
Taking a patch like this through net{-next} could cause a merge
problem at Linus' level if a later patch makes it though the normal
process and conflicts. This is what I want to avoid.
This patch, although appreciated, isn't critical. I have collected it
into my tree and will re-post it to scsi-misc. I see no reason to treat
this patch differently from other patches.
Ultimately I just want things to go smoothly, so I'll leave it up to
James and you to figure out what to do.
Thanks, //Rob
^ permalink raw reply
* [net-next-2.6 PATCH 1/3] net: dcbnl: Update copyright dates
From: John Fastabend @ 2011-03-14 19:01 UTC (permalink / raw)
To: davem; +Cc: mark.d.rustad, netdev, shmulikr
From: Mark Rustad <mark.d.rustad@intel.com>
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
include/linux/dcbnl.h | 2 +-
net/dcb/dcbnl.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
index a3680a1..97c90b9 100644
--- a/include/linux/dcbnl.h
+++ b/include/linux/dcbnl.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2008, Intel Corporation.
+ * Copyright (c) 2008-2011, Intel Corporation.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
index 118392f..3609eac 100644
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2008, Intel Corporation.
+ * Copyright (c) 2008-2011, Intel Corporation.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
^ permalink raw reply related
* [net-next-2.6 PATCH 2/3] net: dcbnl: Fix misspellings
From: John Fastabend @ 2011-03-14 19:01 UTC (permalink / raw)
To: davem; +Cc: mark.d.rustad, netdev, shmulikr
In-Reply-To: <20110314190102.12070.21182.stgit@jf-dev1-dcblab>
From: Mark Rustad <mark.d.rustad@intel.com>
Fix a few spelling errors in dcbnl.h.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
include/linux/dcbnl.h | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
index 97c90b9..eedf79b 100644
--- a/include/linux/dcbnl.h
+++ b/include/linux/dcbnl.h
@@ -26,13 +26,13 @@
#define IEEE_8021QAZ_MAX_TCS 8
#define IEEE_8021QAZ_TSA_STRICT 0
-#define IEEE_8021QAZ_TSA_CB_SHABER 1
+#define IEEE_8021QAZ_TSA_CB_SHAPER 1
#define IEEE_8021QAZ_TSA_ETS 2
#define IEEE_8021QAZ_TSA_VENDOR 255
/* This structure contains the IEEE 802.1Qaz ETS managed object
*
- * @willing: willing bit in ETS configuratin TLV
+ * @willing: willing bit in ETS configuration TLV
* @ets_cap: indicates supported capacity of ets feature
* @cbs: credit based shaper ets algorithm supported
* @tc_tx_bw: tc tx bandwidth indexed by traffic class
@@ -92,7 +92,7 @@ struct ieee_pfc {
#define CEE_DCBX_MAX_PRIO 8
/**
- * struct cee_pg - CEE Prioity-Group managed object
+ * struct cee_pg - CEE Priority-Group managed object
*
* @willing: willing bit in the PG tlv
* @error: error bit in the PG tlv
^ permalink raw reply related
* Re: [GIT/PATCH v5] xen network backend driver
From: Eric Dumazet @ 2011-03-14 18:57 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev@vger.kernel.org, xen-devel, Jeremy Fitzhardinge,
Herbert Xu, Konrad Rzeszutek Wilk, Francois Romieu, Ben Hutchings,
Stephen Hemminger, Michał Mirosław
In-Reply-To: <1300112879.17339.2162.camel@zakaz.uk.xensource.com>
Le lundi 14 mars 2011 à 14:27 +0000, Ian Campbell a écrit :
...
> +struct xenvif {
> + /* Unique identifier for this interface. */
> + domid_t domid;
> + unsigned int handle;
> +
> + /* Reference to netback processing backend. */
> + struct xen_netbk *netbk;
> +
> + u8 fe_dev_addr[6];
> +
> + /* Physical parameters of the comms window. */
> + grant_handle_t tx_shmem_handle;
> + grant_ref_t tx_shmem_ref;
> + grant_handle_t rx_shmem_handle;
> + grant_ref_t rx_shmem_ref;
> + unsigned int irq;
> +
> + /* List of frontends to notify after a batch of frames sent. */
> + struct list_head notify_list;
> +
> + /* The shared rings and indexes. */
> + struct xen_netif_tx_back_ring tx;
> + struct xen_netif_rx_back_ring rx;
> + struct vm_struct *tx_comms_area;
> + struct vm_struct *rx_comms_area;
> +
> + /* Flags that must not be set in dev->features */
> + u32 features_disabled;
> +
> + /* Frontend feature information. */
> + u8 can_sg:1;
> + u8 gso:1;
> + u8 gso_prefix:1;
> + u8 csum:1;
> +
> + /* Internal feature information. */
> + u8 can_queue:1; /* can queue packets for receiver? */
> +
> + /*
> + * Allow xenvif_start_xmit() to peek ahead in the rx request
> + * ring. This is a prediction of what rx_req_cons will be
> + * once all queued skbs are put on the ring.
> + */
> + RING_IDX rx_req_cons_peek;
> +
> + /* Transmit shaping: allow 'credit_bytes' every 'credit_usec'. */
> + unsigned long credit_bytes;
> + unsigned long credit_usec;
> + unsigned long remaining_credit;
> + struct timer_list credit_timeout;
> +
> + /* Statistics */
> + unsigned long rx_gso_checksum_fixup;
this is an "unsigned long" field
> +
> + /* Miscellaneous private stuff. */
> + struct list_head schedule_list;
> + atomic_t refcnt;
> + struct net_device *dev;
> +
> + wait_queue_head_t waiting_to_free;
> +};
> +
> +static void xenvif_get_ethtool_stats(struct net_device *dev,
> + struct ethtool_stats *stats, u64 * data)
> +{
> + void *vif = netdev_priv(dev);
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(xenvif_stats); i++)
> + data[i] = *(int *)(vif + xenvif_stats[i].offset);
so use : data[i] = *(unsigned long *)(vif + xenvif_stats[i].offset);
> +}
> +
^ permalink raw reply
* [net-next-2.6 PATCH 3/3] net: dcbnl: Add IEEE app selector value definitions
From: John Fastabend @ 2011-03-14 19:01 UTC (permalink / raw)
To: davem; +Cc: mark.d.rustad, netdev, shmulikr
In-Reply-To: <20110314190102.12070.21182.stgit@jf-dev1-dcblab>
From: Mark Rustad <mark.d.rustad@intel.com>
This adds defines for the app selector values currently
defined in the IEEE 802.1Qaz specification.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
include/linux/dcbnl.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
index eedf79b..c522800 100644
--- a/include/linux/dcbnl.h
+++ b/include/linux/dcbnl.h
@@ -125,6 +125,11 @@ struct cee_pfc {
__u8 tcs_supported;
};
+/* IEEE 802.1Qaz std supported values */
+#define IEEE_8021QAZ_APP_SEL_ETHERTYPE 1
+#define IEEE_8021QAZ_APP_SEL_STREAM 2
+#define IEEE_8021QAZ_APP_SEL_DGRAM 3
+#define IEEE_8021QAZ_APP_SEL_ANY 4
/* This structure contains the IEEE 802.1Qaz APP managed object. This
* object is also used for the CEE std as well. There is no difference
^ permalink raw reply related
* Re: [PATCH] tcp: avoid cwnd moderation in undo
From: Yuchung Cheng @ 2011-03-14 19:10 UTC (permalink / raw)
To: Carsten Wolff; +Cc: David Miller, Ilpo Jarvinen, Nandita Dukkipati, netdev
In-Reply-To: <201103141106.19679.carsten@wolffcarsten.de>
On Mon, Mar 14, 2011 at 3:06 AM, Carsten Wolff <carsten@wolffcarsten.de> wrote:
> The moderation is in place to avoid gigantic segment bursts, which could cause
> unnecessary pressure on buffers. In my eyes it's already suboptimal that the
> moderation is weakened in the presence of (detected) reordering, let alone
> removing it completely.
In the presence of reordering, cwnd is already moderated in Disorder
state before
entering the (false) recovery.
>
> More importantly, the prior ssthresh is restored and not affected by
> moderation. This means, if moderation reduces cwnd to a small value, then cwnd
> < ssthresh and TCP will quickly slow-start back to the previous state, without
> sending a big burst of segments.
>
> Also, you intended to remove cwnd moderation only from an undo during
> recovery, but I think your patch also removes cwnd moderation when the undo is
> caused by D-SACK, i.e. most likely after recovery already ended.
Thanks. I will update my patch description. But the same principle
applies that cwnd
should not be moderated on false events. Whether it should be moderated on
reordering or other events is another (complex) design issue. But this
patch does not
touch that.
Yuchung
^ permalink raw reply
* [PATCH][v2] dev : fix mtu check when TSO is enabled
From: Daniel Lezcano @ 2011-03-14 19:10 UTC (permalink / raw)
To: davem; +Cc: eric.dumazet, kaber, nightnord, netdev
In case the device where is coming from the packet has TSO enabled,
we should not check the mtu size value as this one could be bigger
than the expected value.
This is the case for the macvlan driver when the lower device has
TSO enabled. The macvlan inherit this feature and forward the packets
without fragmenting them. Then the packets go through dev_forward_skb
and are dropped. This patch fix this by checking TSO is not enabled
when we want to check the mtu size.
Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Andrian Nord <nightnord@gmail.com>
---
net/core/dev.c | 24 ++++++++++++++++++++++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 6561021..f1607a0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1503,6 +1503,27 @@ static inline void net_timestamp_check(struct sk_buff *skb)
__net_timestamp(skb);
}
+static inline bool is_skb_forwardable(struct net_device *dev,
+ struct sk_buff *skb)
+{
+ unsigned int len;
+
+ if (!dev->flags & IFF_UP)
+ return false;
+
+ /* we should not check the mtu size if TSO is enabled otherwise
+ * we may have a packet with a length bigger than the expected
+ * one as it was not segmented before */
+ if (skb->dev && skb->dev->features & NETIF_F_TSO)
+ return true;
+
+ len = dev->mtu + dev->hard_header_len + VLAN_HLEN;
+ if (skb->len > len)
+ return false;
+
+ return true;
+}
+
/**
* dev_forward_skb - loopback an skb to another netif
*
@@ -1526,8 +1547,7 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
skb_orphan(skb);
nf_reset(skb);
- if (unlikely(!(dev->flags & IFF_UP) ||
- (skb->len > (dev->mtu + dev->hard_header_len + VLAN_HLEN)))) {
+ if (unlikely(!is_skb_forwardable(dev, skb))) {
atomic_long_inc(&dev->rx_dropped);
kfree_skb(skb);
return NET_RX_DROP;
--
1.7.1
^ permalink raw reply related
* Re: fcoe: correct checking for bonding
From: Jiri Pirko @ 2011-03-14 19:22 UTC (permalink / raw)
To: Robert Love
Cc: David Miller, James.Bottomley@suse.de, linux-scsi@vger.kernel.org,
devel@open-fcoe.org, netdev@vger.kernel.org, fubar@us.ibm.com,
joe.eykholt@gmail.com
In-Reply-To: <1300129447.19083.258.camel@fritz>
Mon, Mar 14, 2011 at 08:04:07PM CET, robert.w.love@intel.com wrote:
>On Sat, 2011-03-12 at 10:59 -0800, David Miller wrote:
>> From: Jiri Pirko <jpirko@redhat.com>
>> Date: Sat, 12 Mar 2011 13:01:10 +0100
>>
>> > Thu, Mar 03, 2011 at 02:09:18AM CET, robert.w.love@intel.com wrote:
>> >>On Wed, 2011-03-02 at 01:55 -0800, Jiri Pirko wrote:
>> >>> Or perhaps this should be applied to net-next?
>> >>>
>> >>I think this should go through scsi-misc as all the other
>> >>libfc/libfcoe/fcoe patches do.
>> >>
>> >>> Wed, Mar 02, 2011 at 07:05:35AM CET, jpirko@redhat.com wrote:
>> >>> >Check for bonding master and refuse to use that.
>> >>> >
>> >>> >Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>> >>> >---
>> >>> > drivers/scsi/fcoe/fcoe.c | 4 +---
>> >>> > 1 files changed, 1 insertions(+), 3 deletions(-)
>> >>> >
>> >>> >diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
>> >>> >index 9f9600b..3becc6a 100644
>> >>> >--- a/drivers/scsi/fcoe/fcoe.c
>> >>> >+++ b/drivers/scsi/fcoe/fcoe.c
>> >>> >@@ -285,9 +285,7 @@ static int fcoe_interface_setup(struct fcoe_interface *fcoe,
>> >>> > }
>> >>> >
>> >>> > /* Do not support for bonding device */
>> >>> >- if ((netdev->priv_flags & IFF_MASTER_ALB) ||
>> >>> >- (netdev->priv_flags & IFF_SLAVE_INACTIVE) ||
>> >>> >- (netdev->priv_flags & IFF_MASTER_8023AD)) {
>> >>> >+ if (netdev->priv_flags & IFF_BONDING && netdev->flags & IFF_MASTER) {
>> >>> > FCOE_NETDEV_DBG(netdev, "Bonded interfaces not supported\n");
>> >>> > return -EOPNOTSUPP;
>> >>> > }
>> >>> >--
>> >>> >1.7.3.4
>> >>> >
>> >>
>> >>James, feel free to pick up this patch. I don't have anything in my fcoe
>> >>tree right now that it would conflict with. I'll also put it in my tree
>> >>and resend if you don't put it into scsi-misc directly.
>> >
>> > What's the status of this? Maybe this should rather go thru net-next
>>
>> Sure, I can take this. I'll look at it later.
>
>Hi Dave,
>
> I'd rather have this patch go through scsi-misc. Most, if not all,
>libfc, libfcoe and fcoe patches have taken this path. The way it has
>been working is that I have been collecting fcoe patches and re-posting
>them to scsi-misc after I have reviewed them and done some basic
>testing.
>
> Taking a patch like this through net{-next} could cause a merge
>problem at Linus' level if a later patch makes it though the normal
>process and conflicts. This is what I want to avoid.
>
> This patch, although appreciated, isn't critical. I have collected it
>into my tree and will re-post it to scsi-misc. I see no reason to treat
>this patch differently from other patches.
Well I have another set of patches dependent on this one :(
>
> Ultimately I just want things to go smoothly, so I'll leave it up to
>James and you to figure out what to do.
>
>Thanks, //Rob
>
^ permalink raw reply
* Re: Occasional link flap on Intel 82599 on boot in XAUI mode
From: Brent Cook @ 2011-03-14 19:21 UTC (permalink / raw)
To: Skidmore, Donald C; +Cc: netdev@vger.kernel.org
In-Reply-To: <29F4ED941D916B48B88B4D2A4F3D1B9C01D30140EF@orsmsx509.amr.corp.intel.com>
On Friday 25 February 2011 12:11:11 Skidmore, Donald C wrote:
> >-----Original Message-----
> >From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> >On Behalf Of Brent Cook
> >Sent: Friday, February 25, 2011 8:12 AM
> >To: netdev@vger.kernel.org
> >Subject: Occasional link flap on Intel 82599 on boot in XAUI mode
> >
> >We have a custom system with dual 82599's in XAUI mode. One has its pair
> >of ports connected to a 10G switch, the other has its pair of ports
> >connected to an FPGA.
> >
> >Occasionally, on any of the interfaces, we will see the links flapping
> >up and down when the system initially boots. This happens maybe one in
> >20 boots.
> >
> >Feb 23 14:58:10 mfg kernel: [ 594.254977] ixgbe: eth1 NIC Link is Down
> >Feb 23 14:58:12 mfg kernel: [ 596.230039] ixgbe: eth1 NIC Link is Up 10
> >Gbps, Flow Control: RX/TX
> >Feb 23 14:58:12 mfg kernel: [ 596.256537] ixgbe: eth1 NIC Link is Down
> >Feb 23 14:58:16 mfg kernel: [ 600.228096] ixgbe: eth1 NIC Link is Up 10
> >Gbps, Flow Control: RX/TX
> >Feb 23 14:58:16 mfg kernel: [ 600.240135] ixgbe: eth1 NIC Link is Down
> >Feb 23 14:58:18 mfg kernel: [ 602.227047] ixgbe: eth1 NIC Link is Up 10
> >Gbps, Flow Control: RX/TX
> >
> >Simply forcing a down/up on the interface seems to correct the problem:
> >
> >ip link set eth1 down
> >ip link set eth1 up
> >
> >Is anyone else using XAUI mode and has seen this? Here is the kernel
> >information that we are using currently:
> >
>
> By any chance have you tried it with a newer driver? Latest Source Forge is 3.2.9.
>
> Also do you only see this link flap on boot, can you recreate the flap by unload and loading the ixgbe module?
>
We updated to the latest source forge driver and had the same behavior. Reloading the driver does not reproduce the issue.
It seems to be related to the remote XAUI peer coming out of reset after the 82599. The FPGAs on one pair of links are loaded in software at boot time, and the switch reset is also delayed slightly compared to the 82599. We fixed the issue by doing 'ethtool -r' once for each link at boot time.
Thanks
- Brent
^ 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