* [PATCH 3/6] tcp_cubic: fix comparison of jiffies
From: Stephen Hemminger @ 2011-03-10 16:51 UTC (permalink / raw)
To: davem, sangtae.ha, rhee; +Cc: netdev
In-Reply-To: <20110310165119.224046957@vyatta.com>
[-- Attachment #1: tcp-cubic-jiffies-wrap.patch --]
[-- Type: text/plain, Size: 952 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.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/ipv4/tcp_cubic.c 2011-03-10 08:08:32.867492953 -0800
+++ b/net/ipv4/tcp_cubic.c 2011-03-10 08:24:39.658201745 -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 0/6] TCP CUBIC and Hystart
From: Stephen Hemminger @ 2011-03-10 16:51 UTC (permalink / raw)
To: davem, sangtae.ha, rhee; +Cc: netdev
This patch set is my attempt at addressing the problems discovered
by Lucas Nussbaum.
^ permalink raw reply
* [PATCH 1/6] tcp: fix RTT for quick packets in congestion control
From: Stephen Hemminger @ 2011-03-10 16:51 UTC (permalink / raw)
To: davem, sangtae.ha, rhee; +Cc: netdev
In-Reply-To: <20110310165119.224046957@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-08 11:11:26.093183654 -0800
+++ b/net/ipv4/tcp_input.c 2011-03-08 11:11:46.641404939 -0800
@@ -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 5/6] tcp_cubic: fix clock dependency
From: Stephen Hemminger @ 2011-03-10 16:51 UTC (permalink / raw)
To: davem, sangtae.ha, rhee; +Cc: netdev
In-Reply-To: <20110310165119.224046957@vyatta.com>
[-- Attachment #1: tcp-cubic-minrtt.patch --]
[-- Type: text/plain, Size: 3050 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.
Warning: this is still experimental, there may still be mistakes
in units (ms vs. jiffies).
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
P.s: tried using ktime_t but 'struct bictcp' is bumping against limit
of CA_PRIV_SIZE.
--- a/net/ipv4/tcp_cubic.c 2011-03-10 08:35:45.532695373 -0800
+++ b/net/ipv4/tcp_cubic.c 2011-03-10 08:35:59.968882888 -0800
@@ -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_ms(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,7 +248,7 @@ 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)
+ t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3) - ca->epoch_start)
<< BICTCP_HZ) / HZ;
if (t < ca->bic_K) /* t - K */
@@ -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 6/6] tcp_cubic: enable high resolution ack time if needed
From: Stephen Hemminger @ 2011-03-10 16:51 UTC (permalink / raw)
To: davem, sangtae.ha, rhee; +Cc: netdev
In-Reply-To: <20110310165119.224046957@vyatta.com>
[-- Attachment #1: tcp-cubic-rtt-cong.patch --]
[-- Type: text/plain, Size: 673 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>
--- a/net/ipv4/tcp_cubic.c 2011-03-10 08:35:59.968882888 -0800
+++ b/net/ipv4/tcp_cubic.c 2011-03-10 08:36:10.241016524 -0800
@@ -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 2/6] tcp: timestamp code clarification
From: Stephen Hemminger @ 2011-03-10 16:51 UTC (permalink / raw)
To: davem, sangtae.ha, rhee; +Cc: netdev
In-Reply-To: <20110310165119.224046957@vyatta.com>
[-- Attachment #1: tcp-input-tstamp-clean.patch --]
[-- Type: text/plain, Size: 1462 bytes --]
Use inline functions to make the checking of ack timestamp clearer.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/ipv4/tcp_input.c 2011-03-10 07:58:37.715948842 -0800
+++ b/net/ipv4/tcp_input.c 2011-03-10 07:58:38.419937963 -0800
@@ -3263,7 +3263,7 @@ static int tcp_clean_rtx_queue(struct so
flag |= FLAG_NONHEAD_RETRANS_ACKED;
} else {
ca_seq_rtt = now - scb->when;
- last_ackt = skb->tstamp;
+ last_ackt = skb_get_ktime(skb);
if (seq_rtt < 0) {
seq_rtt = ca_seq_rtt;
}
@@ -3345,9 +3345,8 @@ static int tcp_clean_rtx_queue(struct so
/* Is the ACK triggering packet unambiguous? */
if (!(flag & FLAG_RETRANS_DATA_ACKED)) {
/* High resolution needed and available? */
- if (ca_ops->flags & TCP_CONG_RTT_STAMP &&
- !ktime_equal(last_ackt,
- net_invalid_timestamp()))
+ if ((ca_ops->flags & TCP_CONG_RTT_STAMP) &&
+ net_timestamp_isvalid(last_ackt))
rtt_us = ktime_us_delta(ktime_get_real(),
last_ackt);
else if (ca_seq_rtt >= 0)
--- a/include/linux/skbuff.h 2011-03-10 07:55:27.181150325 -0800
+++ b/include/linux/skbuff.h 2011-03-10 07:58:38.419937963 -0800
@@ -1965,6 +1965,11 @@ static inline ktime_t net_invalid_timest
return ktime_set(0, 0);
}
+static inline bool net_timestamp_isvalid(ktime_t t)
+{
+ return !ktime_equal(t, net_invalid_timestamp());
+}
+
extern void skb_timestamping_init(void);
#ifdef CONFIG_NETWORK_PHY_TIMESTAMPING
^ permalink raw reply
* [PATCH] phylib: SIOCGMIIREG/SIOCSMIIREG: allow access to all mdio addresses
From: Peter Korsgaard @ 2011-03-10 16:52 UTC (permalink / raw)
To: davem, netdev; +Cc: Peter Korsgaard
phylib would silently ignore the phy_id argument to these ioctls and
perform the read/write with the active phydev address, whereas most
non-phylib drivers seem to allow access to all mdio addresses
(E.G. pcnet_cs).
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
drivers/net/phy/phy.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index a8445c7..f767033 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -319,7 +319,8 @@ int phy_mii_ioctl(struct phy_device *phydev,
/* fall through */
case SIOCGMIIREG:
- mii_data->val_out = phy_read(phydev, mii_data->reg_num);
+ mii_data->val_out = mdiobus_read(phydev->bus, mii_data->phy_id,
+ mii_data->reg_num);
break;
case SIOCSMIIREG:
@@ -350,8 +351,9 @@ int phy_mii_ioctl(struct phy_device *phydev,
}
}
- phy_write(phydev, mii_data->reg_num, val);
-
+ mdiobus_write(phydev->bus, mii_data->phy_id,
+ mii_data->reg_num, val);
+
if (mii_data->reg_num == MII_BMCR &&
val & BMCR_RESET &&
phydev->drv->config_init) {
--
1.7.2.3
^ permalink raw reply related
* [PATCH] can : TI_HECC : Unintialized variables
From: Abhilash K V @ 2011-03-10 16:21 UTC (permalink / raw)
To: socketcan-core, netdev, linux-kernel
Cc: wg, linux-omap, Abhilash K V, Vaibhav Hiremath
1. In ti_hecc_xmit(), "data" is not initialized, causing
undesirable effects like setting the RTR field for every
transmit.
2. In ti_hecc_probe(), the spinlock priv->mbx_lock is not
inited, causing a spinlock lockup BUG.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Anant Gole <anantgole@ti.com>
Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
---
drivers/net/can/ti_hecc.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index 4d07f1e..73c6025 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -503,6 +503,7 @@ static netdev_tx_t ti_hecc_xmit(struct sk_buff *skb, struct net_device *ndev)
spin_unlock_irqrestore(&priv->mbx_lock, flags);
/* Prepare mailbox for transmission */
+ data = cf->can_dlc;
if (cf->can_id & CAN_RTR_FLAG) /* Remote transmission request */
data |= HECC_CANMCF_RTR;
data |= get_tx_head_prio(priv) << 8;
@@ -923,6 +924,7 @@ static int ti_hecc_probe(struct platform_device *pdev)
priv->can.do_get_state = ti_hecc_get_state;
priv->can.ctrlmode_supported = CAN_CTRLMODE_3_SAMPLES;
+ spin_lock_init(&priv->mbx_lock);
ndev->irq = irq->start;
ndev->flags |= IFF_ECHO;
platform_set_drvdata(pdev, ndev);
--
1.6.2.4
^ permalink raw reply related
* [PATCH] bridge: skip forwarding delay if not using STP
From: Stephen Hemminger @ 2011-03-10 15:57 UTC (permalink / raw)
To: David Miller; +Cc: bridge, netdev
f Spanning Tree Protocol is not enabled, there is no good reason for
the bridge code to wait for the forwarding delay period before enabling
the link. The purpose of the forwarding delay is to allow STP to
learn about other bridges before nominating itself.
The only possible impact is that when starting up a new port
the bridge may flood a packet now, where previously it might have
seen traffic from the other host and preseeded the forwarding table.
Includes change for local variable br already available in that func.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/bridge/br_stp.c 2011-03-07 14:56:45.660973568 -0800
+++ b/net/bridge/br_stp.c 2011-03-07 14:57:47.373590362 -0800
@@ -375,12 +375,12 @@ static void br_make_forwarding(struct ne
if (p->state != BR_STATE_BLOCKING)
return;
- if (br->forward_delay == 0) {
+ if (br->stp_enabled == BR_NO_STP || br->forward_delay == 0) {
p->state = BR_STATE_FORWARDING;
br_topology_change_detection(br);
del_timer(&p->forward_delay_timer);
}
- else if (p->br->stp_enabled == BR_KERNEL_STP)
+ else if (br->stp_enabled == BR_KERNEL_STP)
p->state = BR_STATE_LISTENING;
else
p->state = BR_STATE_LEARNING;
^ permalink raw reply
* Re: [PATCH 3/3 V2] slab,rcu: don't assume the size of struct rcu_head
From: Christoph Lameter @ 2011-03-10 15:36 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Pekka Enberg, Ingo Molnar, Paul E. McKenney, Eric Dumazet,
David S. Miller, Matt Mackall, linux-mm, linux-kernel, netdev
In-Reply-To: <4D787C30.1020407@cn.fujitsu.com>
Acked-by: Christoph Lameter <cl@linux.com>
^ permalink raw reply
* Re: [PATCH 2/3 V2] slub,rcu: don't assume the size of struct rcu_head
From: Christoph Lameter @ 2011-03-10 15:36 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Ingo Molnar, Pekka Enberg, Paul E. McKenney, Eric Dumazet,
David S. Miller, Matt Mackall, linux-mm, linux-kernel, netdev
In-Reply-To: <4D787C18.3070800@cn.fujitsu.com>
Acked-by: Christoph Lameter <cl@linux.com>
^ permalink raw reply
* Re: [PATCH 1/3 V2] slub: automatically reserve bytes at the end of slab
From: Christoph Lameter @ 2011-03-10 15:35 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Ingo Molnar, Pekka Enberg, Paul E. McKenney, Eric Dumazet,
David S. Miller, Matt Mackall, linux-mm, linux-kernel, netdev
In-Reply-To: <4D787C0C.7040707@cn.fujitsu.com>
Acked-by: Christoph Lameter <cl@linux.com>
^ permalink raw reply
* Re: Network performance with small packets - continued
From: Michael S. Tsirkin @ 2011-03-10 15:34 UTC (permalink / raw)
To: Tom Lendacky
Cc: Shirley Ma, Rusty Russell, Krishna Kumar2, David Miller, kvm,
netdev, steved
In-Reply-To: <201103100923.44184.tahm@linux.vnet.ibm.com>
On Thu, Mar 10, 2011 at 09:23:42AM -0600, Tom Lendacky wrote:
> On Thursday, March 10, 2011 12:54:58 am Michael S. Tsirkin wrote:
> > On Wed, Mar 09, 2011 at 05:25:11PM -0600, Tom Lendacky wrote:
> > > As for which CPU the interrupt gets pinned to, that doesn't matter - see
> > > below.
> >
> > So what hurts us the most is that the IRQ jumps between the VCPUs?
>
> Yes, it appears that allowing the IRQ to run on more than one vCPU hurts.
> Without the publish last used index patch, vhost keeps injecting an irq for
> every received packet until the guest eventually turns off notifications.
Are you sure you see that? If yes publish used should help a lot.
> Because the irq injections end up overlapping we get contention on the
> irq_desc_lock_class lock. Here are some results using the "baseline" setup
> with irqbalance running.
>
> Txn Rate: 107,714.53 Txn/Sec, Pkt Rate: 214,006 Pkts/Sec
> Exits: 121,050.45 Exits/Sec
> TxCPU: 9.61% RxCPU: 99.45%
> Virtio1-input Interrupts/Sec (CPU0/CPU1): 13,975/0
> Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
>
> About a 24% increase over baseline. Irqbalance essentially pinned the virtio
> irq to CPU0 preventing the irq lock contention and resulting in nice gains.
OK, so we probably want some form of delayed free for TX
on top, and that should get us nice results already.
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" 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
* [patch] libertas: fix write past end of array in mesh_id_get()
From: Dan Carpenter @ 2011-03-10 15:23 UTC (permalink / raw)
To: Dan Williams, javier
Cc: John W. Linville, libertas-dev, linux-wireless, netdev,
kernel-janitors
defs.meshie.val.mesh_id is 32 chars long. It's not supposed to be NUL
terminated. This code puts a terminator on the end to make it easier to
print to sysfs. The problem is that if the mesh_id fills the entire
buffer the original code puts the terminator one spot past the end.
The way the original code was written, there was a check to make sure
that maxlen was less than PAGE_SIZE. Since we know that maxlen is at
most 34 chars, I just removed the check.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/wireless/libertas/mesh.c b/drivers/net/wireless/libertas/mesh.c
index acf3bf6..9d097b9 100644
--- a/drivers/net/wireless/libertas/mesh.c
+++ b/drivers/net/wireless/libertas/mesh.c
@@ -918,7 +918,6 @@ static ssize_t mesh_id_get(struct device *dev, struct device_attribute *attr,
char *buf)
{
struct mrvl_mesh_defaults defs;
- int maxlen;
int ret;
ret = mesh_get_default_parameters(dev, &defs);
@@ -931,13 +930,11 @@ static ssize_t mesh_id_get(struct device *dev, struct device_attribute *attr,
defs.meshie.val.mesh_id_len = IEEE80211_MAX_SSID_LEN;
}
- /* SSID not null terminated: reserve room for \0 + \n */
- maxlen = defs.meshie.val.mesh_id_len + 2;
- maxlen = (PAGE_SIZE > maxlen) ? maxlen : PAGE_SIZE;
+ memcpy(buf, defs.meshie.val.mesh_id, defs.meshie.val.mesh_id_len);
+ buf[defs.meshie.val.mesh_id_len] = '\n';
+ buf[defs.meshie.val.mesh_id_len + 1] = '\0';
- defs.meshie.val.mesh_id[defs.meshie.val.mesh_id_len] = '\0';
-
- return snprintf(buf, maxlen, "%s\n", defs.meshie.val.mesh_id);
+ return defs.meshie.val.mesh_id_len + 1;
}
/**
^ permalink raw reply related
* Re: Network performance with small packets - continued
From: Tom Lendacky @ 2011-03-10 15:23 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Shirley Ma, Rusty Russell, Krishna Kumar2, David Miller, kvm,
netdev, steved
In-Reply-To: <20110310065457.GA22820@redhat.com>
On Thursday, March 10, 2011 12:54:58 am Michael S. Tsirkin wrote:
> On Wed, Mar 09, 2011 at 05:25:11PM -0600, Tom Lendacky wrote:
> > As for which CPU the interrupt gets pinned to, that doesn't matter - see
> > below.
>
> So what hurts us the most is that the IRQ jumps between the VCPUs?
Yes, it appears that allowing the IRQ to run on more than one vCPU hurts.
Without the publish last used index patch, vhost keeps injecting an irq for
every received packet until the guest eventually turns off notifications.
Because the irq injections end up overlapping we get contention on the
irq_desc_lock_class lock. Here are some results using the "baseline" setup
with irqbalance running.
Txn Rate: 107,714.53 Txn/Sec, Pkt Rate: 214,006 Pkts/Sec
Exits: 121,050.45 Exits/Sec
TxCPU: 9.61% RxCPU: 99.45%
Virtio1-input Interrupts/Sec (CPU0/CPU1): 13,975/0
Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
About a 24% increase over baseline. Irqbalance essentially pinned the virtio
irq to CPU0 preventing the irq lock contention and resulting in nice gains.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" 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] Make CUBIC Hystart more robust to RTT variations
From: Injong Rhee @ 2011-03-10 14:37 UTC (permalink / raw)
To: Bill Fink
Cc: Lucas Nussbaum, Stephen Hemminger, David Miller, xiyou.wangcong,
netdev, sangtae.ha
In-Reply-To: <20110310002458.5a94f563.billfink@mindspring.com>
This is a good example why I think the problem is in implementation. The
original idea is sound. The tests where Lucas report problems in (fat
pipes with only a small # of flows) are the ones where hystart should
perform very well. If you have many flows, then leaving slow start early
(even if by mistake) can be easily covered by cubic growth function in
congestion avoidance.
We need to look into the issue of Hz setting, other implementation
issues, and run more extensive tests.
On 3/10/11 12:24 AM, Bill Fink wrote:
> On Wed, 9 Mar 2011, Lucas Nussbaum wrote:
>
>> On 08/03/11 at 20:30 -0500, Injong Rhee wrote:
>>> Now, both tools can be wrong. But that is not catastrophic since
>>> congestion avoidance can kick in to save the day. In a pipe where no
>>> other flows are competing, then exiting slow start too early can
>>> slow things down as the window can be still too small. But that is
>>> in fact when delays are most reliable. So those tests that say bad
>>> performance with hystart are in fact, where hystart is supposed to
>>> perform well.
>> Hi,
>>
>> In my setup, there is no congestion at all (except the buffer bloat).
>> Without Hystart, transferring 8 Gb of data takes 9s, with CUBIC exiting
>> slow start at ~2000 packets.
>> With Hystart, transferring 8 Gb of data takes 19s, with CUBIC exiting
>> slow start at ~20 packets.
>> I don't think that this is "hystart performing well". We could just as
>> well remove slow start completely, and only do congestion avoidance,
>> then.
>>
>> While I see the value in Hystart, it's clear that there are some flaws
>> in the current implementation. It probably makes sense to disable
>> hystart by default until those problems are fixed.
> Here are some tests I performed across real networks, where
> congestion is generally not an issue, with a 2.6.35 kernel on
> the transmit side.
>
> 8 GB transfer across an 18 ms RTT path with autotuning and hystart:
>
> i7test7% nuttcp -n8g -i1 192.168.1.23
> 517.9375 MB / 1.00 sec = 4344.6096 Mbps 0 retrans
> 688.4375 MB / 1.00 sec = 5775.1998 Mbps 0 retrans
> 692.9375 MB / 1.00 sec = 5812.7462 Mbps 0 retrans
> 698.0625 MB / 1.00 sec = 5855.8078 Mbps 0 retrans
> 699.8750 MB / 1.00 sec = 5871.0123 Mbps 0 retrans
> 710.5625 MB / 1.00 sec = 5960.5707 Mbps 0 retrans
> 728.8125 MB / 1.00 sec = 6113.7652 Mbps 0 retrans
> 751.3750 MB / 1.00 sec = 6302.9210 Mbps 0 retrans
> 783.8750 MB / 1.00 sec = 6575.6201 Mbps 0 retrans
> 825.1875 MB / 1.00 sec = 6921.8145 Mbps 0 retrans
> 875.4375 MB / 1.00 sec = 7343.9811 Mbps 0 retrans
>
> 8192.0000 MB / 11.26 sec = 6102.4718 Mbps 11 %TX 28 %RX 0 retrans 18.92 msRTT
>
> Ramps up quickly to a little under 6 Gbps, then increases more
> slowly to 7+ Gbps, with no TCP retransmissions.
>
> 8 GB transfer across an 18 ms RTT path with 40 MB socket buffer and hystart:
>
> i7test7% nuttcp -n8g -w40m -i1 192.168.1.23
> 970.0625 MB / 1.00 sec = 8136.8475 Mbps 0 retrans
> 1181.1875 MB / 1.00 sec = 9909.0045 Mbps 0 retrans
> 1181.2500 MB / 1.00 sec = 9908.6369 Mbps 0 retrans
> 1181.3125 MB / 1.00 sec = 9909.8747 Mbps 0 retrans
> 1181.2500 MB / 1.00 sec = 9909.0531 Mbps 0 retrans
> 1181.2500 MB / 1.00 sec = 9908.8153 Mbps 0 retrans
> 1181.2500 MB / 1.00 sec = 9909.0729 Mbps 0 retrans
>
> 8192.0000 MB / 7.13 sec = 9633.5814 Mbps 17 %TX 42 %RX 0 retrans 18.91 msRTT
>
> Quickly ramps up to full 10-GigE line rate, with no TCP retrans.
>
> 8 GB transfer across an 18 ms RTT path with autotuning and no hystart:
>
> i7test7% nuttcp -n8g -i1 192.168.1.23
> 845.4375 MB / 1.00 sec = 7091.5828 Mbps 0 retrans
> 1181.3125 MB / 1.00 sec = 9910.0134 Mbps 0 retrans
> 1181.0625 MB / 1.00 sec = 9907.1830 Mbps 0 retrans
> 1181.4375 MB / 1.00 sec = 9910.8936 Mbps 0 retrans
> 1181.1875 MB / 1.00 sec = 9908.1721 Mbps 0 retrans
> 1181.3125 MB / 1.00 sec = 9909.5774 Mbps 0 retrans
> 1181.1875 MB / 1.00 sec = 9908.6874 Mbps 0 retrans
>
> 8192.0000 MB / 7.25 sec = 9484.4524 Mbps 18 %TX 41 %RX 0 retrans 18.92 msRTT
>
> Also quickly ramps up to full 10-GigE line rate, with no TCP retrans.
>
> 8 GB transfer across an 18 ms RTT path with 40 MB socket buffer and no hystart:
>
> i7test7% nuttcp -n8g -w40m -i1 192.168.1.23
> 969.8750 MB / 1.00 sec = 8135.6571 Mbps 0 retrans
> 1181.3125 MB / 1.00 sec = 9909.3990 Mbps 0 retrans
> 1181.2500 MB / 1.00 sec = 9908.9342 Mbps 0 retrans
> 1181.2500 MB / 1.00 sec = 9909.4098 Mbps 0 retrans
> 1181.2500 MB / 1.00 sec = 9908.8252 Mbps 0 retrans
> 1181.2500 MB / 1.00 sec = 9909.0630 Mbps 0 retrans
> 1181.2500 MB / 1.00 sec = 9909.3504 Mbps 0 retrans
>
> 8192.0000 MB / 7.15 sec = 9611.8053 Mbps 18 %TX 42 %RX 0 retrans 18.95 msRTT
>
> Basically the same as the case with 40 MB socket buffer and hystart enabled.
>
> Now trying the same type of tests across an 80 ms RTT path.
>
> 8 GB transfer across an 80 ms RTT path with autotuning and hystart:
>
> i7test7% nuttcp -n8g -i1 192.168.1.18
> 11.3125 MB / 1.00 sec = 94.8954 Mbps 0 retrans
> 441.5625 MB / 1.00 sec = 3704.1021 Mbps 0 retrans
> 687.3750 MB / 1.00 sec = 5765.8657 Mbps 0 retrans
> 715.5625 MB / 1.00 sec = 6002.6273 Mbps 0 retrans
> 709.9375 MB / 1.00 sec = 5955.5958 Mbps 0 retrans
> 691.3125 MB / 1.00 sec = 5799.0626 Mbps 0 retrans
> 718.6250 MB / 1.00 sec = 6028.3538 Mbps 0 retrans
> 718.0000 MB / 1.00 sec = 6023.0205 Mbps 0 retrans
> 704.0000 MB / 1.00 sec = 5905.5387 Mbps 0 retrans
> 733.3125 MB / 1.00 sec = 6151.4096 Mbps 0 retrans
> 738.8750 MB / 1.00 sec = 6198.2381 Mbps 0 retrans
> 731.8750 MB / 1.00 sec = 6139.3695 Mbps 0 retrans
>
> 8192.0000 MB / 12.85 sec = 5348.9677 Mbps 10 %TX 23 %RX 0 retrans 80.81 msRTT
>
> Similar to the 20 ms RTT path, but achieving somewhat lower
> performance levels, presumably due to the larger RTT. Ramps
> up fairly quickly to a little under 6 Gbps, then increases
> more slowly to 6+ Gbps, with no TCP retransmissions.
>
> 8 GB transfer across an 80 ms RTT path with 100 MB socket buffer and hystart:
>
> i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
> 103.9375 MB / 1.00 sec = 871.8378 Mbps 0 retrans
> 1086.5625 MB / 1.00 sec = 9114.6102 Mbps 0 retrans
> 1106.6875 MB / 1.00 sec = 9283.5583 Mbps 0 retrans
> 1109.3125 MB / 1.00 sec = 9305.5226 Mbps 0 retrans
> 1111.1875 MB / 1.00 sec = 9321.9596 Mbps 0 retrans
> 1112.8125 MB / 1.00 sec = 9334.8452 Mbps 0 retrans
> 1113.6875 MB / 1.00 sec = 9341.6620 Mbps 0 retrans
> 1120.2500 MB / 1.00 sec = 9398.0054 Mbps 0 retrans
>
> 8192.0000 MB / 8.37 sec = 8207.2049 Mbps 16 %TX 38 %RX 0 retrans 80.81 msRTT
>
> Quickly ramps up to 9+ Gbps and then slowly increases further,
> with no TCP retrans.
>
> 8 GB transfer across an 80 ms RTT path with autotuning and no hystart:
>
> i7test7% nuttcp -n8g -i1 192.168.1.18
> 11.2500 MB / 1.00 sec = 94.3703 Mbps 0 retrans
> 519.0625 MB / 1.00 sec = 4354.1596 Mbps 0 retrans
> 861.2500 MB / 1.00 sec = 7224.7970 Mbps 0 retrans
> 871.0000 MB / 1.00 sec = 7306.4191 Mbps 0 retrans
> 860.7500 MB / 1.00 sec = 7220.4438 Mbps 0 retrans
> 869.0625 MB / 1.00 sec = 7290.3340 Mbps 0 retrans
> 863.4375 MB / 1.00 sec = 7242.7707 Mbps 0 retrans
> 860.4375 MB / 1.00 sec = 7218.0606 Mbps 0 retrans
> 875.5000 MB / 1.00 sec = 7344.3071 Mbps 0 retrans
> 863.1875 MB / 1.00 sec = 7240.8257 Mbps 0 retrans
>
> 8192.0000 MB / 10.98 sec = 6259.4379 Mbps 12 %TX 27 %RX 0 retrans 80.81 msRTT
>
> Ramps up quickly to 7+ Gbps, then appears to stabilize at that
> level, with no TCP retransmissions. Performance is somewhat
> better than with autotuning enabled, but less than using a
> manually set 100 MB socket buffer.
>
> 8 GB transfer across an 80 ms RTT path with 100 MB socket buffer and no hystart:
>
> i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
> 102.8750 MB / 1.00 sec = 862.9487 Mbps 0 retrans
> 522.8750 MB / 1.00 sec = 4386.2811 Mbps 414 retrans
> 881.5625 MB / 1.00 sec = 7394.6534 Mbps 0 retrans
> 1164.3125 MB / 1.00 sec = 9766.6682 Mbps 0 retrans
> 1170.5625 MB / 1.00 sec = 9819.7042 Mbps 0 retrans
> 1166.8125 MB / 1.00 sec = 9788.2067 Mbps 0 retrans
> 1159.8750 MB / 1.00 sec = 9729.1530 Mbps 0 retrans
> 811.1250 MB / 1.00 sec = 6804.8017 Mbps 21 retrans
> 73.2500 MB / 1.00 sec = 614.4674 Mbps 0 retrans
> 884.6250 MB / 1.00 sec = 7420.2900 Mbps 0 retrans
>
> 8192.0000 MB / 10.34 sec = 6647.9394 Mbps 13 %TX 31 %RX 435 retrans 80.81 msRTT
>
> Disabling hystart on a large RTT path does not seem to play nice with
> a manually specified socket buffer, resulting in TCP retransmissions
> that limit the effective network performance.
>
> This is a repeatable but extremely variable phenomenon.
>
> i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
> 103.7500 MB / 1.00 sec = 870.3015 Mbps 0 retrans
> 1146.3750 MB / 1.00 sec = 9616.4520 Mbps 0 retrans
> 1175.9375 MB / 1.00 sec = 9864.6070 Mbps 0 retrans
> 615.6875 MB / 1.00 sec = 5164.7353 Mbps 21 retrans
> 139.2500 MB / 1.00 sec = 1168.1253 Mbps 0 retrans
> 1090.0625 MB / 1.00 sec = 9143.8053 Mbps 0 retrans
> 1170.4375 MB / 1.00 sec = 9818.6654 Mbps 0 retrans
> 1174.5625 MB / 1.00 sec = 9852.8754 Mbps 0 retrans
> 1174.8750 MB / 1.00 sec = 9855.6052 Mbps 0 retrans
>
> 8192.0000 MB / 9.42 sec = 7292.9879 Mbps 14 %TX 34 %RX 21 retrans 80.81 msRTT
>
> And:
>
> i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
> 102.8125 MB / 1.00 sec = 862.4227 Mbps 0 retrans
> 1148.4375 MB / 1.00 sec = 9633.6860 Mbps 0 retrans
> 1177.4375 MB / 1.00 sec = 9877.3086 Mbps 0 retrans
> 1168.1250 MB / 1.00 sec = 9798.9133 Mbps 11 retrans
> 133.1250 MB / 1.00 sec = 1116.7457 Mbps 0 retrans
> 479.8750 MB / 1.00 sec = 4025.4631 Mbps 0 retrans
> 1150.6875 MB / 1.00 sec = 9652.4830 Mbps 0 retrans
> 1177.3125 MB / 1.00 sec = 9876.0624 Mbps 0 retrans
> 1177.3750 MB / 1.00 sec = 9876.0139 Mbps 0 retrans
> 320.2500 MB / 1.00 sec = 2686.6452 Mbps 19 retrans
> 64.9375 MB / 1.00 sec = 544.7363 Mbps 0 retrans
> 73.6250 MB / 1.00 sec = 617.6113 Mbps 0 retrans
>
> 8192.0000 MB / 12.39 sec = 5545.7570 Mbps 12 %TX 26 %RX 30 retrans 80.80 msRTT
>
> Re-enabling hystart immediately gives a clean test with no TCP retrans.
>
> i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
> 103.8750 MB / 1.00 sec = 871.3353 Mbps 0 retrans
> 1086.7500 MB / 1.00 sec = 9116.4474 Mbps 0 retrans
> 1105.8125 MB / 1.00 sec = 9276.2276 Mbps 0 retrans
> 1109.4375 MB / 1.00 sec = 9306.5339 Mbps 0 retrans
> 1111.3125 MB / 1.00 sec = 9322.5327 Mbps 0 retrans
> 1111.3750 MB / 1.00 sec = 9322.8053 Mbps 0 retrans
> 1113.7500 MB / 1.00 sec = 9342.8962 Mbps 0 retrans
> 1120.3125 MB / 1.00 sec = 9397.5711 Mbps 0 retrans
>
> 8192.0000 MB / 8.38 sec = 8204.8394 Mbps 16 %TX 39 %RX 0 retrans 80.80 msRTT
>
> -Bill
^ permalink raw reply
* Re: [PATCH 1/8] macb: unify at91 and avr32 platform data
From: Jamie Iles @ 2011-03-10 13:17 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: Jamie Iles, netdev, linux-arm-kernel
In-Reply-To: <4D78CCBC.2010807@atmel.com>
On Thu, Mar 10, 2011 at 02:06:04PM +0100, Nicolas Ferre wrote:
> On 3/10/2011 11:10 AM, Jamie Iles :
> > --- a/drivers/net/macb.c
> > +++ b/drivers/net/macb.c
> > @@ -18,12 +18,10 @@
> > #include <linux/netdevice.h>
> > #include <linux/etherdevice.h>
> > #include <linux/dma-mapping.h>
> > +#include <linux/platform_data/macb.h>
> > #include <linux/platform_device.h>
> > #include <linux/phy.h>
> >
> > -#include <mach/board.h>
> > -#include <mach/cpu.h>
>
> I did not bouble check but do we need no more cpu_is_ macros?
No, I couldn't see any in there and it builds for all of the AT91
targets and all of the AVR32 ones that I tried. I can't see any macros
in there that are likely to use cpu_is_* internally either.
Jamie
^ permalink raw reply
* Re: [PATCH 1/8] macb: unify at91 and avr32 platform data
From: Nicolas Ferre @ 2011-03-10 13:06 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1299751843-9743-2-git-send-email-jamie@jamieiles.com>
On 3/10/2011 11:10 AM, Jamie Iles :
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -18,12 +18,10 @@
> #include <linux/netdevice.h>
> #include <linux/etherdevice.h>
> #include <linux/dma-mapping.h>
> +#include <linux/platform_data/macb.h>
> #include <linux/platform_device.h>
> #include <linux/phy.h>
>
> -#include <mach/board.h>
> -#include <mach/cpu.h>
I did not bouble check but do we need no more cpu_is_ macros?
> -
> #include "macb.h"
>
> #define RX_BUFFER_SIZE 128
--
Nicolas Ferre
^ permalink raw reply
* Re: Mass udp flow reboot linux with RealTek RTL-8169 Gigabit
From: Francois Romieu @ 2011-03-10 12:08 UTC (permalink / raw)
To: Seblu; +Cc: Eric Dumazet, lkml, netdev, Ivan Vecera
In-Reply-To: <AANLkTim6tt4yC+1VQ3AtDMf1KKLRqf5kErpipqNSbQkX@mail.gmail.com>
Seblu <seblu@seblu.net> :
[...]
> I catched the following trace during my previous torture session.
> Maybe it can help.
It's the usual r8169 TX timeout watchdog.
[...]
> > Can you apply the two attached patches on top of the previous ones and
> > give it a try ? The debug should not be too verbose if things are stationary
> > enough.
> 2.6.38-rc7 with your 2 previous patch change the game. No reboot. No
> strange message in dmesg.
?
"strange message" as :
[ ] netdev watchdog messages
[ ] 0001 0001 0001 0001 (or similar) message
[ ] net_ratelimit message
> But some sent packets are lost from some host. Example:
[...]
> This is maybe normal under stress, card discard packet after all.
It seems so. 0.08% packet loss. 10 ~ 20kpps (right ?). Sample at 0.1 Hz (ping).
[...]
> I've a serial cable and a second computer, but my first computer
> doesn't have a com port. Is it then possible?
Hardly. Forget it for now.
> Do you need more test?
1. 2.6.38-rc7 without the patches
2. 2.6.38-rc7 with the r8169.c driver of 2.6.38-rc5, without the patches
3. current setup + pktgen. Lower the packet size as long as it increases
the sender's pps.
I do not understand why the bug would be gone if it was in the r8169
proper.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 2/8] macb: detect hclk presence from platform data
From: Jamie Iles @ 2011-03-10 11:45 UTC (permalink / raw)
To: Jamie Iles
Cc: Russell King - ARM Linux, netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <20110310114137.GC6198@pulham.picochip.com>
On Thu, Mar 10, 2011 at 11:41:37AM +0000, Jamie Iles wrote:
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index bfd3601..8e6d8e3 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -246,9 +246,7 @@ static int macb_mii_init(struct macb *bp)
> bp->mii_bus->parent = &bp->dev->dev;
> pdata = bp->pdev->dev.platform_data;
>
> - if (pdata)
> - bp->mii_bus->phy_mask = pdata->phy_mask;
> -
> + bp->mii_bus->phy_mask = pdata->phy_mask;
> bp->mii_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
> if (!bp->mii_bus->irq) {
> err = -ENOMEM;
Doh, too hasty. That hunk shouldn't be there now. I'll fix that up for
next time.
Jamie
^ permalink raw reply
* Re: [PATCH 2/8] macb: detect hclk presence from platform data
From: Jamie Iles @ 2011-03-10 11:41 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jamie Iles, netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <20110310101554.GD11273@n2100.arm.linux.org.uk>
On Thu, Mar 10, 2011 at 10:15:54AM +0000, Russell King - ARM Linux wrote:
> On Thu, Mar 10, 2011 at 10:10:37AM +0000, Jamie Iles wrote:
> > Rather than detecting whether we need to do a clk_get() and enable on
> > the "hclk" based on the kernel configuration, add an extra field to the
> > platform data. This makes it cleaner to add more supported
> > architectures without lots of ifdeffery.
>
> Why not have the platform provide a dummy hclk if no real hclk exists?
Yes, that would be much better. In that case, this patch can be
replaced with the two below. I'll repost the series with the other
patches refreshed, but I'd like someone with AT91 knowledge to check
that at91_clock_associate() is doing what I think it is first.
This also means that the driver doesn't need a conditional on ARCH_AT91
for the pclk name.
Jamie
>From 11dc6ca059e848295db8c0c534ece196e8f9ff37 Mon Sep 17 00:00:00 2001
From: Jamie Iles <jamie@jamieiles.com>
Date: Thu, 10 Mar 2011 11:11:20 +0000
Subject: [PATCH 1/2] at91: provide pclk and hclk for macb ethernet devices
AT91 has a "macb_pclk" which is used to control the clock to the
Ethernet controller, but this is a different name to the AVR32
devices that use "pclk". Associate the clock with the names "pclk"
and "hclk" and the macb driver doesn't need to handle the two
architectures differently.
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
arch/arm/mach-at91/at572d940hf_devices.c | 3 +++
arch/arm/mach-at91/at91cap9_devices.c | 3 +++
arch/arm/mach-at91/at91rm9200_devices.c | 3 +++
arch/arm/mach-at91/at91sam9260_devices.c | 3 +++
arch/arm/mach-at91/at91sam9263_devices.c | 3 +++
arch/arm/mach-at91/at91sam9g45_devices.c | 3 +++
6 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-at91/at572d940hf_devices.c b/arch/arm/mach-at91/at572d940hf_devices.c
index 6e1b9a3..9234b4e 100644
--- a/arch/arm/mach-at91/at572d940hf_devices.c
+++ b/arch/arm/mach-at91/at572d940hf_devices.c
@@ -192,6 +192,9 @@ void __init at91_add_device_eth(struct eth_platform_data *data)
at91_set_A_periph(AT91_PIN_PA13, 0); /* EMDIO */
at91_set_A_periph(AT91_PIN_PA14, 0); /* EMDC */
+ at91_clock_associate("macb_clk", &at572d940hf_eth_device.dev, "pclk");
+ at91_clock_associate("macb_clk", &at572d940hf_eth_device.dev, "hclk");
+
eth_data = *data;
platform_device_register(&at572d940hf_eth_device);
}
diff --git a/arch/arm/mach-at91/at91cap9_devices.c b/arch/arm/mach-at91/at91cap9_devices.c
index e041743..5c57885 100644
--- a/arch/arm/mach-at91/at91cap9_devices.c
+++ b/arch/arm/mach-at91/at91cap9_devices.c
@@ -258,6 +258,9 @@ void __init at91_add_device_eth(struct eth_platform_data *data)
at91_set_B_periph(AT91_PIN_PC24, 0); /* ETXER */
}
+ at91_clock_associate("macb_clk", &at91cap9_eth_device.dev, "pclk");
+ at91_clock_associate("macb_clk", &at91cap9_eth_device.dev, "hclk");
+
eth_data = *data;
platform_device_register(&at91cap9_eth_device);
}
diff --git a/arch/arm/mach-at91/at91rm9200_devices.c b/arch/arm/mach-at91/at91rm9200_devices.c
index 5f873d5..e7b8ec3 100644
--- a/arch/arm/mach-at91/at91rm9200_devices.c
+++ b/arch/arm/mach-at91/at91rm9200_devices.c
@@ -187,6 +187,9 @@ void __init at91_add_device_eth(struct eth_platform_data *data)
at91_set_B_periph(AT91_PIN_PB12, 0); /* ETX2 */
}
+ at91_clock_associate("macb_clk", &at91rm9200_eth_device.dev, "pclk");
+ at91_clock_associate("macb_clk", &at91rm9200_eth_device.dev, "hclk");
+
eth_data = *data;
platform_device_register(&at91rm9200_eth_device);
}
diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
index e172b46..9ff8592 100644
--- a/arch/arm/mach-at91/at91sam9260_devices.c
+++ b/arch/arm/mach-at91/at91sam9260_devices.c
@@ -188,6 +188,9 @@ void __init at91_add_device_eth(struct eth_platform_data *data)
at91_set_B_periph(AT91_PIN_PA22, 0); /* ETXER */
}
+ at91_clock_associate("macb_clk", &at91sam9260_eth_device.dev, "pclk");
+ at91_clock_associate("macb_clk", &at91sam9260_eth_device.dev, "hclk");
+
eth_data = *data;
platform_device_register(&at91sam9260_eth_device);
}
diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
index 416613c..46560e9 100644
--- a/arch/arm/mach-at91/at91sam9263_devices.c
+++ b/arch/arm/mach-at91/at91sam9263_devices.c
@@ -198,6 +198,9 @@ void __init at91_add_device_eth(struct eth_platform_data *data)
at91_set_B_periph(AT91_PIN_PC24, 0); /* ETXER */
}
+ at91_clock_associate("macb_clk", &at91sam9263_eth_device.dev, "pclk");
+ at91_clock_associate("macb_clk", &at91sam9263_eth_device.dev, "hclk");
+
eth_data = *data;
platform_device_register(&at91sam9263_eth_device);
}
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index 0867343..ab46ae7 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -343,6 +343,9 @@ void __init at91_add_device_eth(struct eth_platform_data *data)
at91_set_B_periph(AT91_PIN_PA27, 0); /* ETXER */
}
+ at91_clock_associate("macb_clk", &at91sam9g45_eth_device.dev, "pclk");
+ at91_clock_associate("macb_clk", &at91sam9g45_eth_device.dev, "hclk");
+
eth_data = *data;
platform_device_register(&at91sam9g45_eth_device);
}
--
1.7.4
>From 7dfd4a15bbb0b5c14be44ebc54c3038423086418 Mon Sep 17 00:00:00 2001
From: Jamie Iles <jamie@jamieiles.com>
Date: Tue, 8 Mar 2011 20:19:23 +0000
Subject: [PATCH 2/2] macb: remove conditional clk handling
AT91 now provides both "pclk" and "hclk" aliases for the the macb
device so we can use the same clk handling paths for both AT91 and
AVR32.
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
drivers/net/macb.c | 27 +++------------------------
1 files changed, 3 insertions(+), 24 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index bfd3601..8e6d8e3 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -246,9 +246,7 @@ static int macb_mii_init(struct macb *bp)
bp->mii_bus->parent = &bp->dev->dev;
pdata = bp->pdev->dev.platform_data;
- if (pdata)
- bp->mii_bus->phy_mask = pdata->phy_mask;
-
+ bp->mii_bus->phy_mask = pdata->phy_mask;
bp->mii_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
if (!bp->mii_bus->irq) {
err = -ENOMEM;
@@ -1138,28 +1136,19 @@ static int __init macb_probe(struct platform_device *pdev)
spin_lock_init(&bp->lock);
-#if defined(CONFIG_ARCH_AT91)
- bp->pclk = clk_get(&pdev->dev, "macb_clk");
+ bp->pclk = clk_get(&pdev->dev, "pclk");
if (IS_ERR(bp->pclk)) {
dev_err(&pdev->dev, "failed to get macb_clk\n");
goto err_out_free_dev;
}
clk_enable(bp->pclk);
-#else
- bp->pclk = clk_get(&pdev->dev, "pclk");
- if (IS_ERR(bp->pclk)) {
- dev_err(&pdev->dev, "failed to get pclk\n");
- goto err_out_free_dev;
- }
+
bp->hclk = clk_get(&pdev->dev, "hclk");
if (IS_ERR(bp->hclk)) {
dev_err(&pdev->dev, "failed to get hclk\n");
goto err_out_put_pclk;
}
-
- clk_enable(bp->pclk);
clk_enable(bp->hclk);
-#endif
bp->regs = ioremap(regs->start, regs->end - regs->start + 1);
if (!bp->regs) {
@@ -1243,14 +1232,10 @@ err_out_free_irq:
err_out_iounmap:
iounmap(bp->regs);
err_out_disable_clocks:
-#ifndef CONFIG_ARCH_AT91
clk_disable(bp->hclk);
clk_put(bp->hclk);
-#endif
clk_disable(bp->pclk);
-#ifndef CONFIG_ARCH_AT91
err_out_put_pclk:
-#endif
clk_put(bp->pclk);
err_out_free_dev:
free_netdev(dev);
@@ -1276,10 +1261,8 @@ static int __exit macb_remove(struct platform_device *pdev)
unregister_netdev(dev);
free_irq(dev->irq, dev);
iounmap(bp->regs);
-#ifndef CONFIG_ARCH_AT91
clk_disable(bp->hclk);
clk_put(bp->hclk);
-#endif
clk_disable(bp->pclk);
clk_put(bp->pclk);
free_netdev(dev);
@@ -1297,9 +1280,7 @@ static int macb_suspend(struct platform_device *pdev, pm_message_t state)
netif_device_detach(netdev);
-#ifndef CONFIG_ARCH_AT91
clk_disable(bp->hclk);
-#endif
clk_disable(bp->pclk);
return 0;
@@ -1311,9 +1292,7 @@ static int macb_resume(struct platform_device *pdev)
struct macb *bp = netdev_priv(netdev);
clk_enable(bp->pclk);
-#ifndef CONFIG_ARCH_AT91
clk_enable(bp->hclk);
-#endif
netif_device_attach(netdev);
--
1.7.4
^ permalink raw reply related
* 2.6.38-rc8 build failure - bridge vs. ipv6
From: Patrick Schaaf @ 2011-03-10 10:07 UTC (permalink / raw)
To: netdev; +Cc: davem
Hi all,
I see a build / link failure:
net/built-in.o: In function `br_ip6_multicast_alloc_query':
/usr/src/linux-2.6.38-rc8/net/bridge/br_multicast.c:448: undefined
reference to `ipv6_dev_get_saddr'
This happens with bridging build-in and ipv6 modular.
The call to ipv6_dev_get_saddr was introduced there between 2.6.38-rc6
and 2.6.38-rc8, the -rc6 built just fine with the same .config
I work around it by making bridge build modular, but you might want to
fix it properly before releasing 2.6.38.
best regards
Patrick
^ permalink raw reply
* 2.6.38-rc8 build failure - bridge vs. ipv6
From: Patrick Schaaf @ 2011-03-10 10:19 UTC (permalink / raw)
To: netdev; +Cc: davem
Hi all,
I see a build / link failure:
net/built-in.o: In function `br_ip6_multicast_alloc_query':
/usr/src/linux-2.6.38-rc8/net/bridge/br_multicast.c:448: undefined
reference to `ipv6_dev_get_saddr'
This happens with bridging build-in and ipv6 modular.
The call to ipv6_dev_get_saddr was introduced there between 2.6.38-rc6
and 2.6.38-rc8, the -rc6 built just fine with the same .config
I work around it by making bridge build modular, but you might want to
fix it properly before releasing 2.6.38.
best regards
Patrick
^ permalink raw reply
* Re: [PATCH 2/8] macb: detect hclk presence from platform data
From: Russell King - ARM Linux @ 2011-03-10 10:15 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <1299751843-9743-3-git-send-email-jamie@jamieiles.com>
On Thu, Mar 10, 2011 at 10:10:37AM +0000, Jamie Iles wrote:
> Rather than detecting whether we need to do a clk_get() and enable on
> the "hclk" based on the kernel configuration, add an extra field to the
> platform data. This makes it cleaner to add more supported
> architectures without lots of ifdeffery.
Why not have the platform provide a dummy hclk if no real hclk exists?
^ permalink raw reply
* [PATCH 8/8] macb: support data bus widths > 32 bits
From: Jamie Iles @ 2011-03-10 10:10 UTC (permalink / raw)
To: netdev, linux-arm-kernel; +Cc: nicolas.ferre, Jamie Iles
In-Reply-To: <1299751843-9743-1-git-send-email-jamie@jamieiles.com>
Some GEM implementations may support data bus widths up to 128 bits.
Allow the platform data to specify the data bus width and let the driver
program it up.
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
drivers/net/macb.c | 5 +++++
drivers/net/macb.h | 3 +++
include/linux/platform_data/macb.h | 6 ++++++
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 2965405..6ecbd69 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -797,6 +797,7 @@ static void macb_reset_hw(struct macb *bp)
static void macb_init_hw(struct macb *bp)
{
u32 config;
+ struct eth_platform_data *pdata = dev_get_platdata(&bp->pdev->dev);
macb_reset_hw(bp);
__macb_set_hwaddr(bp);
@@ -810,6 +811,8 @@ static void macb_init_hw(struct macb *bp)
config |= MACB_BIT(CAF); /* Copy All Frames */
if (!(bp->dev->flags & IFF_BROADCAST))
config |= MACB_BIT(NBC); /* No BroadCast */
+ if (bp->is_gem)
+ config |= GEM_BF(DBW, pdata->dbw); /* Data bus width. */
macb_writel(bp, NCFGR, config);
/* Initialize TX and RX buffers */
@@ -1292,6 +1295,8 @@ static int __macb_probe(struct platform_device *pdev, int is_gem)
pclk_hz = clk_get_rate(bp->pclk);
config = bp->is_gem ? gem_mdc_clk_div(pclk_hz) :
macb_mdc_clk_div(pclk_hz);
+ if (bp->is_gem)
+ config |= GEM_BF(DBW, pdata->dbw); /* Data bus width. */
macb_writel(bp, NCFGR, config);
macb_get_hwaddr(bp);
diff --git a/drivers/net/macb.h b/drivers/net/macb.h
index bc2e2c0..cd63c1b 100644
--- a/drivers/net/macb.h
+++ b/drivers/net/macb.h
@@ -134,6 +134,9 @@
/* GEM specific NCFGR bitfields. */
#define GEM_CLK_OFFSET 18
#define GEM_CLK_SIZE 3
+#define GEM_DBW_OFFSET 21
+#define GEM_DBW_SIZE 2
+
/* Bitfields in NSR */
#define MACB_NSR_LINK_OFFSET 0
#define MACB_NSR_LINK_SIZE 1
diff --git a/include/linux/platform_data/macb.h b/include/linux/platform_data/macb.h
index ae18579..d11bfab 100644
--- a/include/linux/platform_data/macb.h
+++ b/include/linux/platform_data/macb.h
@@ -1,11 +1,17 @@
#ifndef __MACB_PDATA_H__
#define __MACB_PDATA_H__
+/* Constants for data bus width. */
+#define MACB_DBW32 0
+#define MACB_DBW64 1
+#define MACB_DBW128 2
+
struct eth_platform_data {
u32 phy_mask;
u8 phy_irq_pin; /* PHY IRQ */
u8 is_rmii; /* using RMII interface? */
int have_hclk; /* have hclk as well as pclk */
+ u8 dbw; /* Data bus width. */
};
#endif /* __MACB_PDATA_H__ */
--
1.7.4
^ permalink raw reply related
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