* [net-next PATCH 2/3] ixgbe: Properly disable DCB arbiters prior to applying changes
From: Jeff Kirsher @ 2009-09-01 23:49 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Peter P Waskiewicz Jr, Jeff Kirsher
In-Reply-To: <20090901234916.4617.73579.stgit@localhost.localdomain>
From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
When disabling the Rx and Tx data arbiters prior to configuration changes,
the arbiters were not being shut down properly. This can create a race
in the DCB hardware blocks, and potentially hang the arbiters. Also, the
Tx descriptor arbiter shouldn't be disabled when applying configuration
changes; disabling this arbiter can cause a Tx hang.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_dcb_82599.c | 21 ++++++++++++++-------
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_dcb_82599.c b/drivers/net/ixgbe/ixgbe_dcb_82599.c
index 589f62c..ec8a252 100644
--- a/drivers/net/ixgbe/ixgbe_dcb_82599.c
+++ b/drivers/net/ixgbe/ixgbe_dcb_82599.c
@@ -145,8 +145,12 @@ s32 ixgbe_dcb_config_rx_arbiter_82599(struct ixgbe_hw *hw,
u32 credit_max = 0;
u8 i = 0;
- /* Disable the arbiter before changing parameters */
- IXGBE_WRITE_REG(hw, IXGBE_RTRPCS, IXGBE_RTRPCS_ARBDIS);
+ /*
+ * Disable the arbiter before changing parameters
+ * (always enable recycle mode; WSP)
+ */
+ reg = IXGBE_RTRPCS_RRM | IXGBE_RTRPCS_RAC | IXGBE_RTRPCS_ARBDIS;
+ IXGBE_WRITE_REG(hw, IXGBE_RTRPCS, reg);
/* Map all traffic classes to their UP, 1 to 1 */
reg = 0;
@@ -194,9 +198,6 @@ s32 ixgbe_dcb_config_tx_desc_arbiter_82599(struct ixgbe_hw *hw,
u32 reg, max_credits;
u8 i;
- /* Disable the arbiter before changing parameters */
- IXGBE_WRITE_REG(hw, IXGBE_RTTDCS, IXGBE_RTTDCS_ARBDIS);
-
/* Clear the per-Tx queue credits; we use per-TC instead */
for (i = 0; i < 128; i++) {
IXGBE_WRITE_REG(hw, IXGBE_RTTDQSEL, i);
@@ -244,8 +245,14 @@ s32 ixgbe_dcb_config_tx_data_arbiter_82599(struct ixgbe_hw *hw,
u32 reg;
u8 i;
- /* Disable the arbiter before changing parameters */
- IXGBE_WRITE_REG(hw, IXGBE_RTTPCS, IXGBE_RTTPCS_ARBDIS);
+ /*
+ * Disable the arbiter before changing parameters
+ * (always enable recycle mode; SP; arb delay)
+ */
+ reg = IXGBE_RTTPCS_TPPAC | IXGBE_RTTPCS_TPRM |
+ (IXGBE_RTTPCS_ARBD_DCB << IXGBE_RTTPCS_ARBD_SHIFT) |
+ IXGBE_RTTPCS_ARBDIS;
+ IXGBE_WRITE_REG(hw, IXGBE_RTTPCS, reg);
/* Map all traffic classes to their UP, 1 to 1 */
reg = 0;
^ permalink raw reply related
* [net-next PATCH 3/3] ixgbe: Patch to fix 82599 multispeed fiber link issues when driver is loaded without any cable and reconnecting it to 1G partner
From: Jeff Kirsher @ 2009-09-01 23:50 UTC (permalink / raw)
To: davem
Cc: netdev, gospo, Mallikarjuna R Chilakala, Peter P Waskiewicz Jr,
Jeff Kirsher
In-Reply-To: <20090901234916.4617.73579.stgit@localhost.localdomain>
From: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
In 82599 multi speed fiber case when driver is loaded without any
cable and reconnecting the cable with a 1G partner does not bring
up the link in 1Gb mode. When there is no link we first setup the link
at 10G & 1G and then try to re-establish the link at highest speed 10G
and thereby changing autoneg_advertised value to highest speed 10G.
After connecting back the cable to a 1G link partner we never try 1G
as autoneg advertised value is changed to link at 10G only. The
following patch fixes the issue by properly initializing the
autoneg_advertised value just before exiting from link setup routine.
Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_82599.c | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_82599.c b/drivers/net/ixgbe/ixgbe_82599.c
index 5ee5608..61af47e 100644
--- a/drivers/net/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ixgbe/ixgbe_82599.c
@@ -421,15 +421,6 @@ s32 ixgbe_setup_mac_link_multispeed_fiber(struct ixgbe_hw *hw,
hw->mac.ops.get_link_capabilities(hw, &phy_link_speed, &negotiation);
speed &= phy_link_speed;
- /* Set autoneg_advertised value based on input link speed */
- hw->phy.autoneg_advertised = 0;
-
- if (speed & IXGBE_LINK_SPEED_10GB_FULL)
- hw->phy.autoneg_advertised |= IXGBE_LINK_SPEED_10GB_FULL;
-
- if (speed & IXGBE_LINK_SPEED_1GB_FULL)
- hw->phy.autoneg_advertised |= IXGBE_LINK_SPEED_1GB_FULL;
-
/*
* When the driver changes the link speeds that it can support,
* it sets autotry_restart to true to indicate that we need to
@@ -466,7 +457,7 @@ s32 ixgbe_setup_mac_link_multispeed_fiber(struct ixgbe_hw *hw,
autoneg,
autoneg_wait_to_complete);
if (status != 0)
- goto out;
+ return status;
/* Flap the tx laser if it has not already been done */
if (hw->mac.autotry_restart) {
@@ -520,7 +511,7 @@ s32 ixgbe_setup_mac_link_multispeed_fiber(struct ixgbe_hw *hw,
autoneg,
autoneg_wait_to_complete);
if (status != 0)
- goto out;
+ return status;
/* Flap the tx laser if it has not already been done */
if (hw->mac.autotry_restart) {
@@ -558,6 +549,15 @@ s32 ixgbe_setup_mac_link_multispeed_fiber(struct ixgbe_hw *hw,
autoneg_wait_to_complete);
out:
+ /* Set autoneg_advertised value based on input link speed */
+ hw->phy.autoneg_advertised = 0;
+
+ if (speed & IXGBE_LINK_SPEED_10GB_FULL)
+ hw->phy.autoneg_advertised |= IXGBE_LINK_SPEED_10GB_FULL;
+
+ if (speed & IXGBE_LINK_SPEED_1GB_FULL)
+ hw->phy.autoneg_advertised |= IXGBE_LINK_SPEED_1GB_FULL;
+
return status;
}
^ permalink raw reply related
* Re: [net-next PATCH 1/3] ixgbe: refactor link setup code
From: David Miller @ 2009-09-02 0:43 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, mallikarjuna.chilakala, peter.p.waskiewicz.jr
In-Reply-To: <20090901234916.4617.73579.stgit@localhost.localdomain>
All 3 patches applied, thanks.
^ permalink raw reply
* Re: [net-next PATCH] e1000: Fix for e1000 kills IPMI on a tagged vlan.
From: David Miller @ 2009-09-02 0:43 UTC (permalink / raw)
To: ole; +Cc: jeffrey.t.kirsher, netdev, gospo, david.graham
In-Reply-To: <alpine.LNX.1.10.0909010247460.5651@bizon.gios.gov.pl>
From: Krzysztof Oledzki <ole@ans.pl>
Date: Tue, 1 Sep 2009 02:53:29 +0200 (CEST)
>
>
> On Mon, 31 Aug 2009, Jeff Kirsher wrote:
>
>> From: Graham, David <david.graham@intel.com>
>
> <CUT>
>> A complete solution to this issue would require further driver
>> changes.
>> The driver would need to discover if (and which) management VLANs are
>> active before enabling VLAN filtering, so that it could ensure that
>> the
>> managed VLANs are included in the VLAN filter table. This discovery
>> requires that the BMC identifies its VLAN in registers accessible
>> to the driver, and at least on Dell PE2850 systems the BMC does not
>> identify its VLAN to allow such discovery. Intel is pursuing this
>> issue
>> with the BMC vendor.
>>
>> Signed-off-by: Dave Graham <david.graham@intel.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Tested-by: Krzysztof Piotr Oledzki <ole@ans.pl>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] macvlan: Use compare_ether_addr_64bits()
From: David Miller @ 2009-09-02 0:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: kaber, netdev
In-Reply-To: <4A9D41BD.9000406@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 01 Sep 2009 17:46:05 +0200
> To speedup ether addresses compares, we can use compare_ether_addr_64bits()
> (all operands are guaranteed to be at least 8 bytes long)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: use compare_ether_addr_64bits() in ALB
From: David Miller @ 2009-09-02 0:44 UTC (permalink / raw)
To: jpirko; +Cc: eric.dumazet, netdev, fubar
In-Reply-To: <20090901181834.GB3209@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Tue, 1 Sep 2009 20:18:35 +0200
> Tue, Sep 01, 2009 at 06:31:18PM CEST, eric.dumazet@gmail.com wrote:
>>We can speedup ether addresses compares using compare_ether_addr_64bits()
>>instead of memcmp(). We make sure all operands are at least 8 bytes long and
>>16bits aligned (or better, long word aligned if possible)
>>
>>Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
...
> Reviewed-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] netns: embed ip6_dst_ops directly
From: David Miller @ 2009-09-02 0:44 UTC (permalink / raw)
To: adobriyan; +Cc: netdev, benjamin.thery, dlezcano
In-Reply-To: <20090829113449.GA3067@x200.localdomain>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Sat, 29 Aug 2009 15:34:49 +0400
> struct net::ipv6.ip6_dst_ops is separatedly dynamically allocated,
> but there is no fundamental reason for it. Embed it directly into
> struct netns_ipv6.
>
> For that:
> * move struct dst_ops into separate header to fix circular dependencies
> I honestly tried not to, it's pretty impossible to do other way
> * drop dynamical allocation, allocate together with netns
>
> For a change, remove struct dst_ops::dst_net, it's deducible
> by using container_of() given dst_ops pointer.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tun: reuse struct sock fields
From: David Miller @ 2009-09-02 0:44 UTC (permalink / raw)
To: mst; +Cc: m.s.tsirkin, netdev, herbert
In-Reply-To: <20090830170442.GA3482@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 30 Aug 2009 20:04:42 +0300
> As tun always has an embeedded struct sock,
> use sk and sk_receive_queue fields instead of
> duplicating them in tun_struct.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sky2: fix management of driver LED
From: David Miller @ 2009-09-02 0:44 UTC (permalink / raw)
To: shemminger; +Cc: mikem, netdev, rene.mayrhofer, leitner
In-Reply-To: <20090831103141.77598705@nehalam>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Mon, 31 Aug 2009 10:31:41 -0700
> Observed by Mike McCormack.
>
> The LED bit here is just a software controlled value used to
> turn on one of the LED's on some boards. The register value was wrong,
> which could have been causing some power control issues.
> Get rid of problematic define use the correct mask.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sky2: Create buffer alloc and free helpers
From: David Miller @ 2009-09-02 0:44 UTC (permalink / raw)
To: mikem; +Cc: netdev
In-Reply-To: <4A9D1FDF.4020407@ring3k.org>
From: Mike McCormack <mikem@ring3k.org>
Date: Tue, 01 Sep 2009 22:21:35 +0900
> Refactor similar two sections of code that free buffers into one.
> Only call tx_init if all buffer allocations succeed.
>
> Signed-off-by: Mike McCormack <mikem@ring3k.org>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sky2: Use 32bit read to read Y2_VAUX_AVAIL
From: David Miller @ 2009-09-02 0:45 UTC (permalink / raw)
To: shemminger; +Cc: mikem, netdev
In-Reply-To: <20090901085757.47b5c09c@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 1 Sep 2009 08:57:57 -0700
> On Tue, 01 Sep 2009 22:54:27 +0900
> Mike McCormack <mikem@ring3k.org> wrote:
>
>> B0_CTST is a 24bit register according to the vendor driver (sk98lin).
>> A 16bit read on B0_CTST will always return 0 for Y2_VAUX_AVAIL (1<<16),
>> so use a 32bit read when testing Y2_VAUX_AVAIL
>>
>> Signed-off-by: Mike McCormack <mikem@ring3k.org>
...
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] RTO connection timeout calculation
From: David Miller @ 2009-09-02 0:45 UTC (permalink / raw)
To: damian; +Cc: netdev
In-Reply-To: <4A9D82DC.50508@tvk.rwth-aachen.de>
From: Damian Lukowski <damian@tvk.rwth-aachen.de>
Date: Tue, 01 Sep 2009 22:23:56 +0200
> this series of patches implements some changes concerning the RTO
> retransmission timeouts.
>
> 1) retransmits_timed_out() is commented shortly and has
> more meaningful names.
> 2) The sysctl documentation is being updated.
>
> Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
Looks good to me, all applied.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: make neigh_ops constant
From: David Miller @ 2009-09-02 0:45 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20090901141319.6ce685e9@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 1 Sep 2009 14:13:19 -0700
>
> These tables are never modified at runtime. Move to read-only
> section.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH] au1000_eth: possible NULL dereference of aup->mii_bus->irq in au1000_probe()
From: David Miller @ 2009-09-02 0:45 UTC (permalink / raw)
To: f.fainelli; +Cc: roel.kluin, netdev, akpm
In-Reply-To: <200908311439.01781.f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 31 Aug 2009 14:38:55 +0200
> Hello Roel,
>
> Le lundi 31 août 2009 10:40:15, Roel Kluin a écrit :
>> aup->mii_bus->irq allocation may fail, prevent a dereference of NULL.
>
> Good catch.
>
>>
>> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
>
> Acked-by: Florian Fainelli <florian@openwrt.org>
Applied.
^ permalink raw reply
* Re: [PATCH] net: sk_free() should be allowed right after sk_alloc()
From: David Miller @ 2009-09-02 0:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: jarkao2, netdev
In-Reply-To: <4A9BBE12.4080206@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 31 Aug 2009 14:12:02 +0200
> David Miller a écrit :
>> From: Jarek Poplawski <jarkao2@gmail.com>
>> Date: Mon, 31 Aug 2009 09:30:19 +0000
>>
>>> On Mon, Aug 31, 2009 at 11:15:36AM +0200, Eric Dumazet wrote:
>>>> From: Jarek Poplawski <jarkao2@gmail.com>
>>>>
>>>> After commit 2b85a34e911bf483c27cfdd124aeb1605145dc80
>>>> (net: No more expensive sock_hold()/sock_put() on each tx)
>>>> sk_free() frees socks conditionally and depends
>>>> on sk_wmem_alloc beeing set e.g. in sock_init_data(). But in some
>>> Very nice, but I hope David could fix btw. my "beeing" misspelling.
>>
>> I will :-)
>
> Thanks :)
Applied to net-2.6, thanks everyone.
^ permalink raw reply
* Re: [PATCH] [V3] net: add Xilinx emac lite device driver
From: David Miller @ 2009-09-02 0:51 UTC (permalink / raw)
To: michal.simek
Cc: john.linn, netdev, linuxppc-dev, jgarzik, grant.likely, jwboyer,
john.williams, sadanan
In-Reply-To: <4A9BCDB4.8040406@petalogix.com>
From: Michal Simek <michal.simek@petalogix.com>
Date: Mon, 31 Aug 2009 15:18:44 +0200
> I see that John's patch has wrong file permission
> -rwxr-xr-x xilinx_emaclite.c
...
> should be 644.
>
> Please fix it in your repo.
Done, thanks!
^ permalink raw reply
* [PATCH]: tasklet_hrtimer revert...
From: David Miller @ 2009-09-02 1:00 UTC (permalink / raw)
To: netdev
I'll push this into net-2.6 shortly...
pkt_sched: Revert tasklet_hrtimer changes.
These are full of unresolved problems, mainly that conversions don't
work 1-1 from hrtimers to tasklet_hrtimers because unlike hrtimers
tasklets can't be killed from softirq context.
And when a qdisc gets reset, that's exactly what we need to do here.
We'll work this out in the net-next-2.6 tree and if warranted we'll
backport that work to -stable.
This reverts the following 3 changesets:
a2cb6a4dd470d7a64255a10b843b0d188416b78f
("pkt_sched: Fix bogon in tasklet_hrtimer changes.")
38acce2d7983632100a9ff3fd20295f6e34074a8
("pkt_sched: Convert CBQ to tasklet_hrtimer.")
ee5f9757ea17759e1ce5503bdae2b07e48e32af9
("pkt_sched: Convert qdisc_watchdog to tasklet_hrtimer")
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/pkt_sched.h | 4 ++--
net/sched/sch_api.c | 10 +++++-----
net/sched/sch_cbq.c | 25 +++++++++++--------------
3 files changed, 18 insertions(+), 21 deletions(-)
diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h
index 7eafb8d..82a3191 100644
--- a/include/net/pkt_sched.h
+++ b/include/net/pkt_sched.h
@@ -61,8 +61,8 @@ psched_tdiff_bounded(psched_time_t tv1, psched_time_t tv2, psched_time_t bound)
}
struct qdisc_watchdog {
- struct tasklet_hrtimer timer;
- struct Qdisc *qdisc;
+ struct hrtimer timer;
+ struct Qdisc *qdisc;
};
extern void qdisc_watchdog_init(struct qdisc_watchdog *wd, struct Qdisc *qdisc);
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index 92e6f3a..24d17ce 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -458,7 +458,7 @@ EXPORT_SYMBOL(qdisc_warn_nonwc);
static enum hrtimer_restart qdisc_watchdog(struct hrtimer *timer)
{
struct qdisc_watchdog *wd = container_of(timer, struct qdisc_watchdog,
- timer.timer);
+ timer);
wd->qdisc->flags &= ~TCQ_F_THROTTLED;
__netif_schedule(qdisc_root(wd->qdisc));
@@ -468,8 +468,8 @@ static enum hrtimer_restart qdisc_watchdog(struct hrtimer *timer)
void qdisc_watchdog_init(struct qdisc_watchdog *wd, struct Qdisc *qdisc)
{
- tasklet_hrtimer_init(&wd->timer, qdisc_watchdog,
- CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+ hrtimer_init(&wd->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+ wd->timer.function = qdisc_watchdog;
wd->qdisc = qdisc;
}
EXPORT_SYMBOL(qdisc_watchdog_init);
@@ -485,13 +485,13 @@ void qdisc_watchdog_schedule(struct qdisc_watchdog *wd, psched_time_t expires)
wd->qdisc->flags |= TCQ_F_THROTTLED;
time = ktime_set(0, 0);
time = ktime_add_ns(time, PSCHED_TICKS2NS(expires));
- tasklet_hrtimer_start(&wd->timer, time, HRTIMER_MODE_ABS);
+ hrtimer_start(&wd->timer, time, HRTIMER_MODE_ABS);
}
EXPORT_SYMBOL(qdisc_watchdog_schedule);
void qdisc_watchdog_cancel(struct qdisc_watchdog *wd)
{
- tasklet_hrtimer_cancel(&wd->timer);
+ hrtimer_cancel(&wd->timer);
wd->qdisc->flags &= ~TCQ_F_THROTTLED;
}
EXPORT_SYMBOL(qdisc_watchdog_cancel);
diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
index 149b040..d5798e1 100644
--- a/net/sched/sch_cbq.c
+++ b/net/sched/sch_cbq.c
@@ -163,7 +163,7 @@ struct cbq_sched_data
psched_time_t now_rt; /* Cached real time */
unsigned pmask;
- struct tasklet_hrtimer delay_timer;
+ struct hrtimer delay_timer;
struct qdisc_watchdog watchdog; /* Watchdog timer,
started when CBQ has
backlog, but cannot
@@ -503,8 +503,6 @@ static void cbq_ovl_delay(struct cbq_class *cl)
cl->undertime = q->now + delay;
if (delay > 0) {
- struct hrtimer *ht;
-
sched += delay + cl->penalty;
cl->penalized = sched;
cl->cpriority = TC_CBQ_MAXPRIO;
@@ -512,12 +510,12 @@ static void cbq_ovl_delay(struct cbq_class *cl)
expires = ktime_set(0, 0);
expires = ktime_add_ns(expires, PSCHED_TICKS2NS(sched));
- ht = &q->delay_timer.timer;
- if (hrtimer_try_to_cancel(ht) &&
- ktime_to_ns(ktime_sub(hrtimer_get_expires(ht),
- expires)) > 0)
- hrtimer_set_expires(ht, expires);
- hrtimer_restart(ht);
+ if (hrtimer_try_to_cancel(&q->delay_timer) &&
+ ktime_to_ns(ktime_sub(
+ hrtimer_get_expires(&q->delay_timer),
+ expires)) > 0)
+ hrtimer_set_expires(&q->delay_timer, expires);
+ hrtimer_restart(&q->delay_timer);
cl->delayed = 1;
cl->xstats.overactions++;
return;
@@ -593,7 +591,7 @@ static psched_tdiff_t cbq_undelay_prio(struct cbq_sched_data *q, int prio,
static enum hrtimer_restart cbq_undelay(struct hrtimer *timer)
{
struct cbq_sched_data *q = container_of(timer, struct cbq_sched_data,
- delay_timer.timer);
+ delay_timer);
struct Qdisc *sch = q->watchdog.qdisc;
psched_time_t now;
psched_tdiff_t delay = 0;
@@ -623,7 +621,7 @@ static enum hrtimer_restart cbq_undelay(struct hrtimer *timer)
time = ktime_set(0, 0);
time = ktime_add_ns(time, PSCHED_TICKS2NS(now + delay));
- tasklet_hrtimer_start(&q->delay_timer, time, HRTIMER_MODE_ABS);
+ hrtimer_start(&q->delay_timer, time, HRTIMER_MODE_ABS);
}
sch->flags &= ~TCQ_F_THROTTLED;
@@ -1216,7 +1214,7 @@ cbq_reset(struct Qdisc* sch)
q->tx_class = NULL;
q->tx_borrowed = NULL;
qdisc_watchdog_cancel(&q->watchdog);
- tasklet_hrtimer_cancel(&q->delay_timer);
+ hrtimer_cancel(&q->delay_timer);
q->toplevel = TC_CBQ_MAXLEVEL;
q->now = psched_get_time();
q->now_rt = q->now;
@@ -1399,8 +1397,7 @@ static int cbq_init(struct Qdisc *sch, struct nlattr *opt)
q->link.minidle = -0x7FFFFFFF;
qdisc_watchdog_init(&q->watchdog, sch);
- tasklet_hrtimer_init(&q->delay_timer, cbq_undelay,
- CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+ hrtimer_init(&q->delay_timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
q->delay_timer.function = cbq_undelay;
q->toplevel = TC_CBQ_MAXLEVEL;
q->now = psched_get_time();
--
1.6.4.2
^ permalink raw reply related
* Re: [PATCH 16/19] intel: convert drivers to netdev_tx_t
From: Jeff Kirsher @ 2009-09-02 1:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev, e1000-devel
In-Reply-To: <20090901055130.042455994@vyatta.com>
On Mon, Aug 31, 2009 at 22:50, Stephen Hemminger<shemminger@vyatta.com> wrote:
> Get rid of some bogus return wrapping as well.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Patch looks fine.
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
^ permalink raw reply
* Re: [PATCH] [net-next] tcp: avoid sending zero TSval
From: David Miller @ 2009-09-02 1:16 UTC (permalink / raw)
To: opurdila; +Cc: netdev
In-Reply-To: <200908312044.56235.opurdila@ixiacom.com>
From: Octavian Purdila <opurdila@ixiacom.com>
Date: Mon, 31 Aug 2009 20:44:56 +0300
> Per RFC1323, zero TSecr is considered invalid. Thus we must avoid when
> possible sending a zero TSval.
>
> Currently, we use the least significant 32 bits of jiffies to fill in
> TSval. But that can wrap around to zero (in 5 minutes after reboot,
> and every 49 days after that in the worst case).
>
> This patch approximate a wrap-around zero TSval to 1. This is better
> then emitting a value which will be ignored.
>
> Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
Ok, I've changed my mind again. I think we need to go with
a solution like this.
Even if we could somehow justify allowing zero timestamps,
I just checked some other stacks and all of them ignore zero
tsecr values. So we can't make that kind of change no matter
what.
This patch needs some changes.
We have to adjust the tests we make against tsecr.
If we bump up a zero jiffies to one in an advertised timestamp,
then we get back a tsecr value of one, and jiffies is still
zero, we should use a comparison value of one not zero.
This is not trivial. You might think it's OK to handle all of
this by just adjusting the definition of tcp_time_stamp but that
gets used by a lot of other things in the stack so those side
effects need to be analyzed.
Grepping around also shows that we also have some code that doesn't
handle jiffies wraparound at all, f.e. check out the rcv_tsecr tests
in net/ipv4/tcp_lp.c :-/
^ permalink raw reply
* Re: [PATCH,v2] Re: e1000e: why does pci_enable_pcie_error_reporting() fail on my hp2510p?
From: Jeff Kirsher @ 2009-09-02 1:18 UTC (permalink / raw)
To: Frans Pop; +Cc: Danny Feng, Netdev, linux-kernel, David Miller
In-Reply-To: <200908210848.39377.elendil@planet.nl>
On Thu, Aug 20, 2009 at 23:48, Frans Pop<elendil@planet.nl> wrote:
> On Friday 21 August 2009, Danny Feng wrote:
>> You may also need to silence pci_disable_pcie_error_reporting,
>> otherwise rmmod/shutdown, you will get
>>
>> e1000e 0000:00:19.0: pci_disable_pcie_error_reporting failed
>
> Yes, thanks. Exactly the same thing there. Updated patch below.
>
>
> From: Frans Pop <elendil@planet.nl>
> Subject: net: Don't report an error if devices don't support AER
>
> The only error returned by pci_{en,dis}able_pcie_error_reporting() is
> -EIO which simply means that Advanced Error Reporting is not supported.
> There is no need to report that, so remove the error check from e1001e,
> igb and ixgbe.
>
> Signed-off-by: Frans Pop <elendil@planet.nl>
>
> diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
> index fa92a68..d67798f 100644
> --- a/drivers/net/e1000e/netdev.c
> +++ b/drivers/net/e1000e/netdev.c
> @@ -4983,12 +4983,7 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
> goto err_pci_reg;
>
> /* AER (Advanced Error Reporting) hooks */
> - err = pci_enable_pcie_error_reporting(pdev);
> - if (err) {
> - dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
> - "0x%x\n", err);
> - /* non-fatal, continue */
> - }
> + pci_enable_pcie_error_reporting(pdev);
>
> pci_set_master(pdev);
> /* PCI config space info */
> @@ -5301,9 +5296,6 @@ static void __devexit e1000_remove(struct pci_dev *pdev)
>
> /* AER disable */
> err = pci_disable_pcie_error_reporting(pdev);
> - if (err)
> - dev_err(&pdev->dev,
> - "pci_disable_pcie_error_reporting failed 0x%x\n", err);
>
> pci_disable_device(pdev);
> }
> diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
> index adb09d3..1533d6f 100644
> --- a/drivers/net/igb/igb_main.c
> +++ b/drivers/net/igb/igb_main.c
> @@ -1232,12 +1232,7 @@ static int __devinit igb_probe(struct pci_dev *pdev,
> if (err)
> goto err_pci_reg;
>
> - err = pci_enable_pcie_error_reporting(pdev);
> - if (err) {
> - dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
> - "0x%x\n", err);
> - /* non-fatal, continue */
> - }
> + pci_enable_pcie_error_reporting(pdev);
>
> pci_set_master(pdev);
> pci_save_state(pdev);
> @@ -1668,9 +1663,6 @@ static void __devexit igb_remove(struct pci_dev *pdev)
> free_netdev(netdev);
>
> err = pci_disable_pcie_error_reporting(pdev);
> - if (err)
> - dev_err(&pdev->dev,
> - "pci_disable_pcie_error_reporting failed 0x%x\n", err);
>
> pci_disable_device(pdev);
> }
> diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
> index 77b0381..777556d 100644
> --- a/drivers/net/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ixgbe/ixgbe_main.c
> @@ -5430,12 +5430,7 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
> goto err_pci_reg;
> }
>
> - err = pci_enable_pcie_error_reporting(pdev);
> - if (err) {
> - dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
> - "0x%x\n", err);
> - /* non-fatal, continue */
> - }
> + pci_enable_pcie_error_reporting(pdev);
>
> pci_set_master(pdev);
> pci_save_state(pdev);
> @@ -5795,9 +5790,6 @@ static void __devexit ixgbe_remove(struct pci_dev *pdev)
> free_netdev(netdev);
>
> err = pci_disable_pcie_error_reporting(pdev);
> - if (err)
> - dev_err(&pdev->dev,
> - "pci_disable_pcie_error_reporting failed 0x%x\n", err);
>
> pci_disable_device(pdev);
> }
Patch looks fine
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
^ permalink raw reply
* Re: [PATCH resend] drop_monitor: fix trace_napi_poll_hit()
From: David Miller @ 2009-09-02 1:20 UTC (permalink / raw)
To: xiaoguangrong; +Cc: nhorman, yjwei, netdev, linux-kernel
In-Reply-To: <4A9B6963.5090207@cn.fujitsu.com>
From: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Date: Mon, 31 Aug 2009 14:10:43 +0800
> The net_dev of backlog napi is NULL, like below:
>
> __get_cpu_var(softnet_data).backlog.dev == NULL
>
> So, we should check it in napi tracepoint's probe function
>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] drop_monitor: make last_rx timestamp private
From: David Miller @ 2009-09-02 1:21 UTC (permalink / raw)
To: nhorman; +Cc: netdev, eric.dumazet
In-Reply-To: <20090831195847.GA6506@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 31 Aug 2009 15:58:47 -0400
> It was recently pointed out to me that the last_rx field of the net_device
> structure wasn't updated regularly. In fact only the bonding driver really uses
> it currently. Since the drop_monitor code relies on the last_rx field to detect
> drops on recevie in hardware, We need to find a more reliable way to rate limit
> our drop checks (so that we don't check for drops on every frame recevied, which
> would be inefficient. This patch makes a last_rx timestamp that is private to
> the drop monitor code and is updated for every device that we track.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Neil, this doesn't apply to net-next-2.6:
> diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
> index 9d66fa9..34a05ce 100644
> --- a/net/core/drop_monitor.c
> +++ b/net/core/drop_monitor.c
...
> @@ -179,18 +180,21 @@ static void trace_napi_poll_hit(struct napi_struct *napi)
> {
> struct dm_hw_stat_delta *new_stat;
>
> - /*
> - * Ratelimit our check time to dm_hw_check_delta jiffies
> - */
> - if (!time_after(jiffies, napi->dev->last_rx + dm_hw_check_delta))
> - return;
>
> rcu_read_lock();
> list_for_each_entry_rcu(new_stat, &hw_stats_list, list) {
In net-next-2.6 this test reads:
/*
* Ratelimit our check time to dm_hw_check_delta jiffies
*/
if (!napi->dev ||
!time_after(jiffies, napi->dev->last_rx + dm_hw_check_delta))
return;
and you must retain the napi->dev NULL check there as otherwise
the list traversal tests will blindly dereference that pointer.
^ permalink raw reply
* Re: [PATCH resend] tracing/events: convert NAPI's tracepoint via TRACE_EVENT
From: David Miller @ 2009-09-02 1:26 UTC (permalink / raw)
To: rostedt
Cc: mingo, xiaoguangrong, nhorman, fweisbec, yjwei, netdev,
linux-kernel
In-Reply-To: <alpine.DEB.2.00.0908311407060.13931@gandalf.stny.rr.com>
From: Steven Rostedt <rostedt@goodmis.org>
Date: Mon, 31 Aug 2009 14:09:04 -0400 (EDT)
>
> On Mon, 31 Aug 2009, Ingo Molnar wrote:
>
>>
>> * Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> wrote:
>>
>> > - Convert NAPI's tracepoint via TRACE_EVENT macro, the output information
>> > like below:
>>
>> I think as long as it does not touch tracing infrastructure (which
>> your patches dont do in their current form) this should be
>> done/merged via the networking tree.
>
> I agree, all changes that are in include/trace/events/ and trace point
> usage can stay within the subsystem tree.
>
>>
>> [ There might be some small collisions in define_trace.h (because
>> these tracepoints move from legacy to new-style TRACE_EVENT()
>> form) but that's OK. ]
>
> But changes to anything in include/trace or kernel/trace needs to go
> throught the tracing subsystem. This includes a changes to define_trace.h.
This patch can't be split up, so I'm wondering how you suggest to
handle this patch given that you have declared that define_trace.h
changes aren't to go through the subsystem tree?
If we do the define_trace.h change only, we break the build
(lack of macro defined for the trace).
If we do only the other parts of his patch, we get a duplicate
definition.
And keep in mind that Neil and Xiao are probably going to want to do
work on top of this to the networking bits. Thus if we put this patch
here into the tracing tree, I'll have to develop a dependency on the
tracing tree and I think that will go over like a fart in a spacesuit
with the -next crowd and Stephen Rothwell in particular.
Please advise.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ip: Report qdisc packet drops
From: David Miller @ 2009-09-02 1:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: cl, sri, dlstevens, netdev, niv, mtk.manpages
In-Reply-To: <4A9BBD8E.2010303@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 31 Aug 2009 14:09:50 +0200
> Re-reading again this stuff, I realized ip6_push_pending_frames()
> was not updating IPSTATS_MIB_OUTDISCARDS, even if IP_RECVERR was set.
>
> May I suggest following path :
>
> 1) Correct ip6_push_pending_frames() to properly
> account for dropped-by-qdisc frames when IP_RECVERR is set
Your patch is applied to net-next-2.6, thanks!
> 2) Submit a patch to account for qdisc-dropped frames in SNMP counters
> but still return a OK to user application, to not break them ?
Sounds good.
I think if you sample random UDP applications, you will find that such
errors will upset them terribly, make them log tons of crap to
/var/log/messages et al., and consume tons of CPU.
And in such cases silent ignoring of drops is entirely appropriate and
optimal, which supports our current behavior.
If we are to make such applications "more sophisticated" such
converted apps can be indicated simply their use of IP_RECVERR.
If you want to be notified of all asynchronous errors we can detect,
you use this, end of story. It is the only way to handle this
situation without breaking the world.
As usual, Alexey Kuznetsov's analysis of this situation is timeless,
accurate, and wise. And he understood all of this 10+ years ago.
^ permalink raw reply
* [PATCH 0/5] Adds implementation of TFRC-SP on DCCP test tree
From: Ivo Calado @ 2009-09-02 2:43 UTC (permalink / raw)
To: dccp; +Cc: netdev
These patches adds implementation of TFRC-SP at the receiver side, and
are targeted at the DCCP branch
Patch #1: First Patch on TFRC-SP. Copy base files from TFRC
Patch #2: Implement loss counting on TFRC-SP receiver
Patch #3: Implement TFRC-SP calc of mean length of loss intervals
accordingly to section 3 of RFC 4828
Patch #4: Adds options DROPPED PACKETS and LOSS INTERVALS to receiver
Patch #5: Updating documentation accordingly
Following this patches, we'll be sending the sender side of TFRC-SP.
Once this code is integrated on the branch, we can proceed adding the
CCID4 code that uses this new TFRC-SP.
--
Ivo Augusto Andrade Rocha Calado
MSc. Candidate
Embedded Systems and Pervasive Computing Lab - http://embedded.ufcg.edu.br
Systems and Computing Department - http://www.dsc.ufcg.edu.br
Electrical Engineering and Informatics Center - http://www.ceei.ufcg.edu.br
Federal University of Campina Grande - http://www.ufcg.edu.br
PGP: 0x03422935
Quidquid latine dictum sit, altum viditur.
^ 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