* Re: How To Temporarily Suspend Network Traffic
From: Rick Jones @ 2011-02-01 17:32 UTC (permalink / raw)
To: Volkan YAZICI; +Cc: netdev
In-Reply-To: <87d3nbakwx.fsf@alamut.ozu.edu.tr>
Volkan YAZICI wrote:
> Hi,
>
> I want to temporarily suspend the network traffic on a particular
> interface -- if possible, in microsecond granularity. For this purpose,
> ifup/ifdown ioctl() calls doesn't work. That is, for wireless
> interfaces, connection isn't get recovered; for wired interfaces, it
> takes at least 2 seconds to recover. I tried using tc, but it doesn't
> accept "rate 0" parameter. Neither "iwconfig wlan0 rate 0" has any
> effect. (Moreover, in iwconfig manual it is told that values below 1000
> are card specific and are usually an index in the bit-rate list.) Do you
> have any suggestions? Can you recommend me to check any code piece in
> the kernel or some other tool?
Out of not quite idle curiousity, what are you trying to accomplish?
Instead of using tc to set a zero rate, you could perhaps try using tc to set a
delay? If it doesn't offer microseconds of delay, pehaps setting a delay and
then eliminating it after your own pause will do what you want - depends of
course on what it is you really want. Your saying you wanted microsecond
granularity suggests you don't want to suspend traffic for very long?
rick jones
>
> Regards.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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: How To Temporarily Suspend Network Traffic
From: Stephen Hemminger @ 2011-02-01 17:49 UTC (permalink / raw)
To: Rick Jones; +Cc: Volkan YAZICI, netdev
In-Reply-To: <4D4843B0.1090803@hp.com>
On Tue, 01 Feb 2011 09:32:32 -0800
Rick Jones <rick.jones2@hp.com> wrote:
> Volkan YAZICI wrote:
> > Hi,
> >
> > I want to temporarily suspend the network traffic on a particular
> > interface -- if possible, in microsecond granularity. For this purpose,
> > ifup/ifdown ioctl() calls doesn't work. That is, for wireless
> > interfaces, connection isn't get recovered; for wired interfaces, it
> > takes at least 2 seconds to recover. I tried using tc, but it doesn't
> > accept "rate 0" parameter. Neither "iwconfig wlan0 rate 0" has any
> > effect. (Moreover, in iwconfig manual it is told that values below 1000
> > are card specific and are usually an index in the bit-rate list.) Do you
> > have any suggestions? Can you recommend me to check any code piece in
> > the kernel or some other tool?
>
> Out of not quite idle curiousity, what are you trying to accomplish?
>
> Instead of using tc to set a zero rate, you could perhaps try using tc to set a
> delay? If it doesn't offer microseconds of delay, pehaps setting a delay and
> then eliminating it after your own pause will do what you want - depends of
> course on what it is you really want. Your saying you wanted microsecond
> granularity suggests you don't want to suspend traffic for very long?
>
> rick jones
What about using tc mired to redirect to dummy device? or use netem drop
^ permalink raw reply
* Re: How To Temporarily Suspend Network Traffic
From: Volkan YAZICI @ 2011-02-01 18:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Rick Jones, netdev
In-Reply-To: <20110201094923.4fa6637f@nehalam>
On Tue, 1 Feb 2011 09:49:23 -0800, Stephen Hemminger writes:
> What about using tc mired to redirect to dummy device? or use netem drop
Ohh! I have just heard about netem. I'll definitely give it a try.
Thanks!
Regards.
P.S. I will ofcourse google and read the documentation that I can find
about these stuff. OTOH, I'd be really appreciated if you can point
me some relevant material. Kind of material, that is, which might
not be able to easily reachable via searching and following links.
^ permalink raw reply
* Re: How To Temporarily Suspend Network Traffic
From: Volkan YAZICI @ 2011-02-01 18:12 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4D4843B0.1090803@hp.com>
On Tue, 01 Feb 2011 09:32:32 -0800, Rick Jones writes:
> Out of not quite idle curiousity, what are you trying to accomplish?
I'm trying to implement a coarse-grained soft-TDMA (Time Division
Multiple Access) among devices in a Wi-Fi network. (Coarse-grained, that
is, compared to a hardware implementation.) Assuming that device clocks
are in sync via NTP, I will figure out the granularity I can achieve
with soft-TDMA.
> Instead of using tc to set a zero rate, you could perhaps try using tc
> to set a delay? If it doesn't offer microseconds of delay, pehaps
> setting a delay and then eliminating it after your own pause will do
> what you want - depends of course on what it is you really want.
Thanks for the advice. I'll check this out and see what I can do.
> Your saying you wanted microsecond granularity suggests you don't want
> to suspend traffic for very long?
I want to figure out the smallest delay that I can achieve in a periodic
manner. (E.g., freeze the traffic for 200us, continue without
interruption for 800us, and freeze the traffic again for another 200us,
etc.) Pay attention that, an undeterministic delay somewhere in between
1000us is not something I prefer, I must be able to determine the point
in time where delay will appear -- ofcourse, with some error margin.
Regards.
^ permalink raw reply
* Re: How To Temporarily Suspend Network Traffic
From: Rick Jones @ 2011-02-01 20:03 UTC (permalink / raw)
To: Volkan YAZICI; +Cc: netdev
In-Reply-To: <87ipx335e1.fsf@alamut.ozu.edu.tr>
Volkan YAZICI wrote:
> On Tue, 01 Feb 2011 09:32:32 -0800, Rick Jones writes:
>
>>Out of not quite idle curiousity, what are you trying to accomplish?
>
> I'm trying to implement a coarse-grained soft-TDMA (Time Division
> Multiple Access) among devices in a Wi-Fi network. (Coarse-grained, that
> is, compared to a hardware implementation.) Assuming that device clocks
> are in sync via NTP, I will figure out the granularity I can achieve
> with soft-TDMA.
As in Fred gets to transmit from 0 to N, Ethel gets to transmit from N+1 to 2N
and so on, based on absolute time?
Getting small number of microsecond synchronization between multiple systems via
NTP (particularly if they are synchronized via a wireless network) may prove
challenging. At least that is my take as a member of the peanut gallery reading
over the shoulders of the discussions that take place in comp.protocols.time.ntp
>>Instead of using tc to set a zero rate, you could perhaps try using tc
>>to set a delay? If it doesn't offer microseconds of delay, pehaps
>>setting a delay and then eliminating it after your own pause will do
>>what you want - depends of course on what it is you really want.
>
> Thanks for the advice. I'll check this out and see what I can do.
>
>>Your saying you wanted microsecond granularity suggests you don't want
>>to suspend traffic for very long?
>
> I want to figure out the smallest delay that I can achieve in a periodic
> manner. (E.g., freeze the traffic for 200us, continue without
> interruption for 800us, and freeze the traffic again for another 200us,
> etc.) Pay attention that, an undeterministic delay somewhere in between
> 1000us is not something I prefer, I must be able to determine the point
> in time where delay will appear -- ofcourse, with some error margin.
Sounds, well, challenging :) The determining the point in time part in
particular. One thing I've learned is that the cell towers in a cell network
sync their time directly to GPS with some kit that is non-trivially expensive.
rick jones
>
>
> Regards.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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: Network performance with small packets
From: Shirley Ma @ 2011-02-01 20:25 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: David Miller, steved, netdev, kvm
In-Reply-To: <20110201201715.GA30050@redhat.com>
On Tue, 2011-02-01 at 22:17 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 01, 2011 at 12:09:03PM -0800, Shirley Ma wrote:
> > On Tue, 2011-02-01 at 19:23 +0200, Michael S. Tsirkin wrote:
> > > On Thu, Jan 27, 2011 at 01:30:38PM -0800, Shirley Ma wrote:
> > > > On Thu, 2011-01-27 at 13:02 -0800, David Miller wrote:
> > > > > > Interesting. Could this is be a variant of the now famuous
> > > > > bufferbloat then?
> > > > >
> > > > > Sigh, bufferbloat is the new global warming... :-/
> > > >
> > > > Yep, some places become colder, some other places become warmer;
> > > Same as
> > > > BW results, sometimes faster, sometimes slower. :)
> > > >
> > > > Shirley
> > >
> > > Sent a tuning patch (v2) that might help.
> > > Could you try it and play with the module parameters please?
> >
> > Hello Michael,
> >
> > Sure I will play with this patch to see how it could help.
> >
> > I am looking at guest side as well, I found a couple issues on guest
> > side:
> >
> > 1. free_old_xmit_skbs() should return the number of skbs instead of
> the
> > total of sgs since we are using ring size to stop/start netif queue.
> > static unsigned int free_old_xmit_skbs(struct virtnet_info *vi)
> > {
> > struct sk_buff *skb;
> > unsigned int len, tot_sgs = 0;
> >
> > while ((skb = virtqueue_get_buf(vi->svq, &len)) != NULL) {
> > pr_debug("Sent skb %p\n", skb);
> > vi->dev->stats.tx_bytes += skb->len;
> > vi->dev->stats.tx_packets++;
> > tot_sgs += skb_vnet_hdr(skb)->num_sg;
> > dev_kfree_skb_any(skb);
> > }
> > return tot_sgs; <---- should return numbers of skbs to track
> > ring usage here, I think;
> > }
> >
> > Did the old guest use number of buffers to track ring usage before?
> >
> > 2. In start_xmit, I think we should move capacity +=
> free_old_xmit_skbs
> > before netif_stop_queue(); so we avoid unnecessary netif queue
> > stop/start. This condition is heavily hit for small message size.
> >
> > Also we capacity checking condition should change to something like
> half
> > of the vring.num size, instead of comparing 2+MAX_SKB_FRAGS?
> >
> > if (capacity < 2+MAX_SKB_FRAGS) {
> > netif_stop_queue(dev);
> > if (unlikely(!virtqueue_enable_cb(vi->svq))) {
> > /* More just got used, free them then
> recheck.
> > */
> > capacity += free_old_xmit_skbs(vi);
> > if (capacity >= 2+MAX_SKB_FRAGS) {
> > netif_start_queue(dev);
> > virtqueue_disable_cb(vi->svq);
> > }
> > }
> > }
> >
> > 3. Looks like the xmit callback is only used to wake the queue when
> the
> > queue has stopped, right? Should we put a condition check here?
> > static void skb_xmit_done(struct virtqueue *svq)
> > {
> > struct virtnet_info *vi = svq->vdev->priv;
> >
> > /* Suppress further interrupts. */
> > virtqueue_disable_cb(svq);
> >
> > /* We were probably waiting for more output buffers. */
> > ---> if (netif_queue_stopped(vi->dev))
> > netif_wake_queue(vi->dev);
> > }
> >
> >
> > Shirley
>
> Well the return value is used to calculate capacity and that counts
> the # of s/g. No?
Nope, the current guest kernel uses descriptors not number of sgs. I am
not sure the old guest.
> From cache utilization POV it might be better to read from the skb and
> not peek at virtio header though...
> Pls Cc the lists on any discussions in the future.
>
> --
> MST
Sorry I missed reply all. :(
Shirley
^ permalink raw reply
* Re: [PATCH] vxge: Fix wrong boolean operator {nodisc}
From: David Miller @ 2011-02-01 20:30 UTC (permalink / raw)
To: Ramkrishna.Vepa
Cc: weil, Sivakumar.Subramani, Sreenivasa.Honnur, netdev,
linux-kernel, Jon.Mason
In-Reply-To: <FCA91A92EE52B041906A0358FC28FCC38EFBE64996@FRE1EXCH02.hq.exar.com>
From: Ramkrishna Vepa <Ramkrishna.Vepa@exar.com>
Date: Mon, 31 Jan 2011 23:26:40 -0800
>> This error is reported by cppcheck:
>> drivers/net/vxge/vxge-config.c:3693: warning: Mutual exclusion over ||
>> always evaluates to true. Did you intend to use && instead?
>>
>> It looks like cppcheck is correct, so fix this. No test was run.
>>
>> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
...
> Fix looks good. Thanks!
>
> Acked-by: Ram Vepa <ram.vepa@exar.com>
Thanks for reviewing, applied.
^ permalink raw reply
* pull request: wireless-2.6 2011-02-01
From: John W. Linville @ 2011-02-01 20:40 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is another batch of fixes intended for 2.6.38.
Included is a firmware upload fix for rtlwifi, a use after free
fix for wl12xx, a memory fix related to PAPRD for ath9k, a couple
of PM-related fixes for ath9k, fixes for race conditions that lead
to crashes in ath9k and ath9k_htc, and a couple of ath5k fixes, one
related to dma error handling and the other an endian fix. A email
address change in the MAINTAINERS entry for wl12xx tops it all off. :-)
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit fca540ab5f4718c6133f71f7be1793066008bf89:
enc28j60: Fix reading of transmit status vector (2011-01-31 20:56:54 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Bob Copeland (2):
ath5k: fix error handling in ath5k_hw_dma_stop
ath5k: correct endianness of frame duration
Chaoming Li (1):
rtlwifi: Fix firmware upload errors
Luciano Coelho (1):
MAINTAINERS: update information for the wl12xx driver
Mathias Krause (1):
wl12xx: fix use after free
Mohammed Shafi Shajakhan (1):
ath9k: Fix memory leak due to failed PAPRD frames
Rajkumar Manoharan (2):
ath9k_hw: Fix system hang when resuming from S3/S4
ath9k: Fix power save usage count imbalance on deinit
Stanislaw Gruszka (2):
ath9k: fix race conditions when stop device
ath9k_htc: fix race conditions when stop device
MAINTAINERS | 6 ++--
drivers/net/wireless/ath/ath5k/dma.c | 4 +-
drivers/net/wireless/ath/ath5k/pcu.c | 4 +--
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 3 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 --
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 21 +++++++++----
drivers/net/wireless/ath/ath9k/init.c | 7 +---
drivers/net/wireless/ath/ath9k/main.c | 19 ++++++++++--
drivers/net/wireless/rtlwifi/efuse.c | 40 ++++++++++++------------
drivers/net/wireless/wl12xx/spi.c | 3 +-
10 files changed, 61 insertions(+), 49 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c9ec9d8..a5deb42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6612,12 +6612,12 @@ S: Maintained
F: drivers/net/wireless/wl1251/*
WL1271 WIRELESS DRIVER
-M: Luciano Coelho <luciano.coelho@nokia.com>
+M: Luciano Coelho <coelho@ti.com>
L: linux-wireless@vger.kernel.org
-W: http://wireless.kernel.org
+W: http://wireless.kernel.org/en/users/Drivers/wl12xx
T: git git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git
S: Maintained
-F: drivers/net/wireless/wl12xx/wl1271*
+F: drivers/net/wireless/wl12xx/
F: include/linux/wl12xx.h
WL3501 WIRELESS PCMCIA CARD DRIVER
diff --git a/drivers/net/wireless/ath/ath5k/dma.c b/drivers/net/wireless/ath/ath5k/dma.c
index 0064be7..21091c2 100644
--- a/drivers/net/wireless/ath/ath5k/dma.c
+++ b/drivers/net/wireless/ath/ath5k/dma.c
@@ -838,9 +838,9 @@ int ath5k_hw_dma_stop(struct ath5k_hw *ah)
for (i = 0; i < qmax; i++) {
err = ath5k_hw_stop_tx_dma(ah, i);
/* -EINVAL -> queue inactive */
- if (err != -EINVAL)
+ if (err && err != -EINVAL)
return err;
}
- return err;
+ return 0;
}
diff --git a/drivers/net/wireless/ath/ath5k/pcu.c b/drivers/net/wireless/ath/ath5k/pcu.c
index e5f2b96..a702817 100644
--- a/drivers/net/wireless/ath/ath5k/pcu.c
+++ b/drivers/net/wireless/ath/ath5k/pcu.c
@@ -86,7 +86,7 @@ int ath5k_hw_get_frame_duration(struct ath5k_hw *ah,
if (!ah->ah_bwmode) {
dur = ieee80211_generic_frame_duration(sc->hw,
NULL, len, rate);
- return dur;
+ return le16_to_cpu(dur);
}
bitrate = rate->bitrate;
@@ -265,8 +265,6 @@ static inline void ath5k_hw_write_rate_duration(struct ath5k_hw *ah)
* what rate we should choose to TX ACKs. */
tx_time = ath5k_hw_get_frame_duration(ah, 10, rate);
- tx_time = le16_to_cpu(tx_time);
-
ath5k_hw_reg_write(ah, tx_time, reg);
if (!(rate->flags & IEEE80211_RATE_SHORT_PREAMBLE))
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_hw.c b/drivers/net/wireless/ath/ath9k/ar9002_hw.c
index f8a7771..f44c84a 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_hw.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_hw.c
@@ -426,9 +426,8 @@ static void ar9002_hw_configpcipowersave(struct ath_hw *ah,
}
/* WAR for ASPM system hang */
- if (AR_SREV_9280(ah) || AR_SREV_9285(ah) || AR_SREV_9287(ah)) {
+ if (AR_SREV_9285(ah) || AR_SREV_9287(ah))
val |= (AR_WA_BIT6 | AR_WA_BIT7);
- }
if (AR_SREV_9285E_20(ah))
val |= AR_WA_BIT23;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 38433f9..0352f09 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -142,9 +142,6 @@ static void ath9k_deinit_priv(struct ath9k_htc_priv *priv)
{
ath9k_htc_exit_debug(priv->ah);
ath9k_hw_deinit(priv->ah);
- tasklet_kill(&priv->swba_tasklet);
- tasklet_kill(&priv->rx_tasklet);
- tasklet_kill(&priv->tx_tasklet);
kfree(priv->ah);
priv->ah = NULL;
}
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index f4d576b..6bb5995 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1025,12 +1025,6 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
int ret = 0;
u8 cmd_rsp;
- /* Cancel all the running timers/work .. */
- cancel_work_sync(&priv->fatal_work);
- cancel_work_sync(&priv->ps_work);
- cancel_delayed_work_sync(&priv->ath9k_led_blink_work);
- ath9k_led_stop_brightness(priv);
-
mutex_lock(&priv->mutex);
if (priv->op_flags & OP_INVALID) {
@@ -1044,8 +1038,23 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
WMI_CMD(WMI_DISABLE_INTR_CMDID);
WMI_CMD(WMI_DRAIN_TXQ_ALL_CMDID);
WMI_CMD(WMI_STOP_RECV_CMDID);
+
+ tasklet_kill(&priv->swba_tasklet);
+ tasklet_kill(&priv->rx_tasklet);
+ tasklet_kill(&priv->tx_tasklet);
+
skb_queue_purge(&priv->tx_queue);
+ mutex_unlock(&priv->mutex);
+
+ /* Cancel all the running timers/work .. */
+ cancel_work_sync(&priv->fatal_work);
+ cancel_work_sync(&priv->ps_work);
+ cancel_delayed_work_sync(&priv->ath9k_led_blink_work);
+ ath9k_led_stop_brightness(priv);
+
+ mutex_lock(&priv->mutex);
+
/* Remove monitor interface here */
if (ah->opmode == NL80211_IFTYPE_MONITOR) {
if (ath9k_htc_remove_monitor_interface(priv))
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 767d8b8..087a6a9 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -598,8 +598,6 @@ err_btcoex:
err_queues:
ath9k_hw_deinit(ah);
err_hw:
- tasklet_kill(&sc->intr_tq);
- tasklet_kill(&sc->bcon_tasklet);
kfree(ah);
sc->sc_ah = NULL;
@@ -807,9 +805,6 @@ static void ath9k_deinit_softc(struct ath_softc *sc)
ath9k_hw_deinit(sc->sc_ah);
- tasklet_kill(&sc->intr_tq);
- tasklet_kill(&sc->bcon_tasklet);
-
kfree(sc->sc_ah);
sc->sc_ah = NULL;
}
@@ -824,6 +819,8 @@ void ath9k_deinit_device(struct ath_softc *sc)
wiphy_rfkill_stop_polling(sc->hw->wiphy);
ath_deinit_leds(sc);
+ ath9k_ps_restore(sc);
+
for (i = 0; i < sc->num_sec_wiphy; i++) {
struct ath_wiphy *aphy = sc->sec_wiphy[i];
if (aphy == NULL)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index c79c97b..9040c2f 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -325,6 +325,8 @@ static bool ath_paprd_send_frame(struct ath_softc *sc, struct sk_buff *skb, int
{
struct ieee80211_hw *hw = sc->hw;
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
+ struct ath_hw *ah = sc->sc_ah;
+ struct ath_common *common = ath9k_hw_common(ah);
struct ath_tx_control txctl;
int time_left;
@@ -342,8 +344,12 @@ static bool ath_paprd_send_frame(struct ath_softc *sc, struct sk_buff *skb, int
init_completion(&sc->paprd_complete);
sc->paprd_pending = true;
txctl.paprd = BIT(chain);
- if (ath_tx_start(hw, skb, &txctl) != 0)
+
+ if (ath_tx_start(hw, skb, &txctl) != 0) {
+ ath_dbg(common, ATH_DBG_XMIT, "PAPRD TX failed\n");
+ dev_kfree_skb_any(skb);
return false;
+ }
time_left = wait_for_completion_timeout(&sc->paprd_complete,
msecs_to_jiffies(ATH_PAPRD_TIMEOUT));
@@ -953,8 +959,6 @@ void ath_radio_disable(struct ath_softc *sc, struct ieee80211_hw *hw)
spin_unlock_bh(&sc->sc_pcu_lock);
ath9k_ps_restore(sc);
-
- ath9k_setpower(sc, ATH9K_PM_FULL_SLEEP);
}
int ath_reset(struct ath_softc *sc, bool retry_tx)
@@ -1309,6 +1313,9 @@ static void ath9k_stop(struct ieee80211_hw *hw)
spin_lock_bh(&sc->sc_pcu_lock);
+ /* prevent tasklets to enable interrupts once we disable them */
+ ah->imask &= ~ATH9K_INT_GLOBAL;
+
/* make sure h/w will not generate any interrupt
* before setting the invalid flag. */
ath9k_hw_disable_interrupts(ah);
@@ -1326,6 +1333,12 @@ static void ath9k_stop(struct ieee80211_hw *hw)
spin_unlock_bh(&sc->sc_pcu_lock);
+ /* we can now sync irq and kill any running tasklets, since we already
+ * disabled interrupts and not holding a spin lock */
+ synchronize_irq(sc->irq);
+ tasklet_kill(&sc->intr_tq);
+ tasklet_kill(&sc->bcon_tasklet);
+
ath9k_ps_restore(sc);
sc->ps_idle = true;
diff --git a/drivers/net/wireless/rtlwifi/efuse.c b/drivers/net/wireless/rtlwifi/efuse.c
index b8433f3..62876cd 100644
--- a/drivers/net/wireless/rtlwifi/efuse.c
+++ b/drivers/net/wireless/rtlwifi/efuse.c
@@ -726,9 +726,9 @@ static int efuse_pg_packet_read(struct ieee80211_hw *hw, u8 offset, u8 *data)
}
static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
- u8 efuse_data, u8 offset, int *bcontinual,
- u8 *write_state, struct pgpkt_struct target_pkt,
- int *repeat_times, int *bresult, u8 word_en)
+ u8 efuse_data, u8 offset, int *bcontinual,
+ u8 *write_state, struct pgpkt_struct *target_pkt,
+ int *repeat_times, int *bresult, u8 word_en)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct pgpkt_struct tmp_pkt;
@@ -744,8 +744,8 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
tmp_pkt.word_en = tmp_header & 0x0F;
tmp_word_cnts = efuse_calculate_word_cnts(tmp_pkt.word_en);
- if (tmp_pkt.offset != target_pkt.offset) {
- efuse_addr = efuse_addr + (tmp_word_cnts * 2) + 1;
+ if (tmp_pkt.offset != target_pkt->offset) {
+ *efuse_addr = *efuse_addr + (tmp_word_cnts * 2) + 1;
*write_state = PG_STATE_HEADER;
} else {
for (tmpindex = 0; tmpindex < (tmp_word_cnts * 2); tmpindex++) {
@@ -756,23 +756,23 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
}
if (bdataempty == false) {
- efuse_addr = efuse_addr + (tmp_word_cnts * 2) + 1;
+ *efuse_addr = *efuse_addr + (tmp_word_cnts * 2) + 1;
*write_state = PG_STATE_HEADER;
} else {
match_word_en = 0x0F;
- if (!((target_pkt.word_en & BIT(0)) |
+ if (!((target_pkt->word_en & BIT(0)) |
(tmp_pkt.word_en & BIT(0))))
match_word_en &= (~BIT(0));
- if (!((target_pkt.word_en & BIT(1)) |
+ if (!((target_pkt->word_en & BIT(1)) |
(tmp_pkt.word_en & BIT(1))))
match_word_en &= (~BIT(1));
- if (!((target_pkt.word_en & BIT(2)) |
+ if (!((target_pkt->word_en & BIT(2)) |
(tmp_pkt.word_en & BIT(2))))
match_word_en &= (~BIT(2));
- if (!((target_pkt.word_en & BIT(3)) |
+ if (!((target_pkt->word_en & BIT(3)) |
(tmp_pkt.word_en & BIT(3))))
match_word_en &= (~BIT(3));
@@ -780,7 +780,7 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
badworden = efuse_word_enable_data_write(
hw, *efuse_addr + 1,
tmp_pkt.word_en,
- target_pkt.data);
+ target_pkt->data);
if (0x0F != (badworden & 0x0F)) {
u8 reorg_offset = offset;
@@ -791,26 +791,26 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
}
tmp_word_en = 0x0F;
- if ((target_pkt.word_en & BIT(0)) ^
+ if ((target_pkt->word_en & BIT(0)) ^
(match_word_en & BIT(0)))
tmp_word_en &= (~BIT(0));
- if ((target_pkt.word_en & BIT(1)) ^
+ if ((target_pkt->word_en & BIT(1)) ^
(match_word_en & BIT(1)))
tmp_word_en &= (~BIT(1));
- if ((target_pkt.word_en & BIT(2)) ^
+ if ((target_pkt->word_en & BIT(2)) ^
(match_word_en & BIT(2)))
tmp_word_en &= (~BIT(2));
- if ((target_pkt.word_en & BIT(3)) ^
+ if ((target_pkt->word_en & BIT(3)) ^
(match_word_en & BIT(3)))
tmp_word_en &= (~BIT(3));
if ((tmp_word_en & 0x0F) != 0x0F) {
*efuse_addr = efuse_get_current_size(hw);
- target_pkt.offset = offset;
- target_pkt.word_en = tmp_word_en;
+ target_pkt->offset = offset;
+ target_pkt->word_en = tmp_word_en;
} else
*bcontinual = false;
*write_state = PG_STATE_HEADER;
@@ -821,8 +821,8 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
}
} else {
*efuse_addr += (2 * tmp_word_cnts) + 1;
- target_pkt.offset = offset;
- target_pkt.word_en = word_en;
+ target_pkt->offset = offset;
+ target_pkt->word_en = word_en;
*write_state = PG_STATE_HEADER;
}
}
@@ -938,7 +938,7 @@ static int efuse_pg_packet_write(struct ieee80211_hw *hw,
efuse_write_data_case1(hw, &efuse_addr,
efuse_data, offset,
&bcontinual,
- &write_state, target_pkt,
+ &write_state, &target_pkt,
&repeat_times, &bresult,
word_en);
else
diff --git a/drivers/net/wireless/wl12xx/spi.c b/drivers/net/wireless/wl12xx/spi.c
index 4671491..7145ea5 100644
--- a/drivers/net/wireless/wl12xx/spi.c
+++ b/drivers/net/wireless/wl12xx/spi.c
@@ -110,9 +110,8 @@ static void wl1271_spi_reset(struct wl1271 *wl)
spi_message_add_tail(&t, &m);
spi_sync(wl_to_spi(wl), &m);
- kfree(cmd);
-
wl1271_dump(DEBUG_SPI, "spi reset -> ", cmd, WSPI_INIT_CMD_LEN);
+ kfree(cmd);
}
static void wl1271_spi_init(struct wl1271 *wl)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PULL] vhost-net: 2.6.38 - warning fix
From: David Miller @ 2011-02-01 20:58 UTC (permalink / raw)
To: mst; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20110201154440.GA22819@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Tue, 1 Feb 2011 17:44:40 +0200
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net
Pulled, thanks Michael.
^ permalink raw reply
* Re: [PATCH] usb:smsc: preserve MAC address when resetting device
From: Sergiy Kibrik @ 2011-02-01 20:58 UTC (permalink / raw)
To: David Lamparter; +Cc: Steve Glendinning, netdev, linux-usb
In-Reply-To: <20110201112425.GA3407894@jupiter.n2.diac24.net>
[-- Attachment #1: Type: Text/Plain, Size: 448 bytes --]
On Tuesday 01 February 2011 13:24:25 David Lamparter wrote:
> You cannot do that. Imagine if I plug in two devices. Only the first one
> will get a MAC properly. Or imagine if i plug a device, unplug it and
> plug it back. It will have an uninitialized mac address.
>
> You need to move the init_mac_address call to happen on device plug-in.
>
>
> -David
Sorry, didn't take into account such case. Will resubmit
-regards,
Sergey
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-01 21:09 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: Steve Dobbelstein, Michael S. Tsirkin, David Miller, kvm,
mashirle, netdev
In-Reply-To: <1296523838.30191.39.camel@sridhar.beaverton.ibm.com>
On Mon, 2011-01-31 at 17:30 -0800, Sridhar Samudrala wrote:
> Yes. It definitely should be 'out'. 'in' should be 0 in the tx path.
>
> I tried a simpler version of this patch without any tunables by
> delaying the signaling until we come out of the for loop.
> It definitely reduced the number of vmexits significantly for small
> message
> guest to host stream test and the throughput went up a little.
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 9b3ca10..5f9fae9 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -197,7 +197,7 @@ static void handle_tx(struct vhost_net *net)
> if (err != len)
> pr_debug("Truncated TX packet: "
> " len %d != %zd\n", err, len);
> - vhost_add_used_and_signal(&net->dev, vq, head, 0);
> + vhost_add_used(vq, head, 0);
> total_len += len;
> if (unlikely(total_len >= VHOST_NET_WEIGHT)) {
> vhost_poll_queue(&vq->poll);
> @@ -205,6 +205,8 @@ static void handle_tx(struct vhost_net *net)
> }
> }
>
> + if (total_len > 0)
> + vhost_signal(&net->dev, vq);
> mutex_unlock(&vq->mutex);
> }
Reducing the signaling will reduce the CPU utilization by reducing VM
exits.
The small message BW is a problem we have seen faster guest/slow vhost,
even I increased VHOST_NET_WEIGHT times, it didn't help that much for
BW. For large message size, vhost is able to process all packets on
time. I played around with guest/host codes, I only see huge BW
improvement by dropping packets on guest side so far.
Thanks
Shirley
^ permalink raw reply
* Re: pull request: wireless-2.6 2011-02-01
From: David Miller @ 2011-02-01 21:10 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20110201204010.GG2560@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 1 Feb 2011 15:40:10 -0500
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Pulled, thanks JOhn.
^ permalink raw reply
* Re: [PATCH] depca: Fix warnings
From: David Miller @ 2011-02-01 21:19 UTC (permalink / raw)
To: alan; +Cc: netdev
In-Reply-To: <20110201113214.24608.34659.stgit@bob.linux.org.uk>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Tue, 01 Feb 2011 11:32:29 +0000
> From: Alan Cox <alan@linux.intel.com>
>
> Replace the rather weird use of ++ with + 1 as the value is being assigned
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
Applied, thanks Alan.
^ permalink raw reply
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-01 21:21 UTC (permalink / raw)
To: Shirley Ma; +Cc: David Miller, steved, netdev, kvm
In-Reply-To: <1296591908.26937.809.camel@localhost.localdomain>
On Tue, Feb 01, 2011 at 12:25:08PM -0800, Shirley Ma wrote:
> On Tue, 2011-02-01 at 22:17 +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 01, 2011 at 12:09:03PM -0800, Shirley Ma wrote:
> > > On Tue, 2011-02-01 at 19:23 +0200, Michael S. Tsirkin wrote:
> > > > On Thu, Jan 27, 2011 at 01:30:38PM -0800, Shirley Ma wrote:
> > > > > On Thu, 2011-01-27 at 13:02 -0800, David Miller wrote:
> > > > > > > Interesting. Could this is be a variant of the now famuous
> > > > > > bufferbloat then?
> > > > > >
> > > > > > Sigh, bufferbloat is the new global warming... :-/
> > > > >
> > > > > Yep, some places become colder, some other places become warmer;
> > > > Same as
> > > > > BW results, sometimes faster, sometimes slower. :)
> > > > >
> > > > > Shirley
> > > >
> > > > Sent a tuning patch (v2) that might help.
> > > > Could you try it and play with the module parameters please?
> > >
> > > Hello Michael,
> > >
> > > Sure I will play with this patch to see how it could help.
> > >
> > > I am looking at guest side as well, I found a couple issues on guest
> > > side:
> > >
> > > 1. free_old_xmit_skbs() should return the number of skbs instead of
> > the
> > > total of sgs since we are using ring size to stop/start netif queue.
> > > static unsigned int free_old_xmit_skbs(struct virtnet_info *vi)
> > > {
> > > struct sk_buff *skb;
> > > unsigned int len, tot_sgs = 0;
> > >
> > > while ((skb = virtqueue_get_buf(vi->svq, &len)) != NULL) {
> > > pr_debug("Sent skb %p\n", skb);
> > > vi->dev->stats.tx_bytes += skb->len;
> > > vi->dev->stats.tx_packets++;
> > > tot_sgs += skb_vnet_hdr(skb)->num_sg;
> > > dev_kfree_skb_any(skb);
> > > }
> > > return tot_sgs; <---- should return numbers of skbs to track
> > > ring usage here, I think;
> > > }
> > >
> > > Did the old guest use number of buffers to track ring usage before?
> > >
> > > 2. In start_xmit, I think we should move capacity +=
> > free_old_xmit_skbs
> > > before netif_stop_queue(); so we avoid unnecessary netif queue
> > > stop/start. This condition is heavily hit for small message size.
> > >
> > > Also we capacity checking condition should change to something like
> > half
> > > of the vring.num size, instead of comparing 2+MAX_SKB_FRAGS?
> > >
> > > if (capacity < 2+MAX_SKB_FRAGS) {
> > > netif_stop_queue(dev);
> > > if (unlikely(!virtqueue_enable_cb(vi->svq))) {
> > > /* More just got used, free them then
> > recheck.
> > > */
> > > capacity += free_old_xmit_skbs(vi);
> > > if (capacity >= 2+MAX_SKB_FRAGS) {
> > > netif_start_queue(dev);
> > > virtqueue_disable_cb(vi->svq);
> > > }
> > > }
> > > }
> > >
> > > 3. Looks like the xmit callback is only used to wake the queue when
> > the
> > > queue has stopped, right? Should we put a condition check here?
> > > static void skb_xmit_done(struct virtqueue *svq)
> > > {
> > > struct virtnet_info *vi = svq->vdev->priv;
> > >
> > > /* Suppress further interrupts. */
> > > virtqueue_disable_cb(svq);
> > >
> > > /* We were probably waiting for more output buffers. */
> > > ---> if (netif_queue_stopped(vi->dev))
> > > netif_wake_queue(vi->dev);
> > > }
> > >
> > >
> > > Shirley
> >
> > Well the return value is used to calculate capacity and that counts
> > the # of s/g. No?
>
> Nope, the current guest kernel uses descriptors not number of sgs.
Confused. We compare capacity to skb frags, no?
That's sg I think ...
> not sure the old guest.
>
> > From cache utilization POV it might be better to read from the skb and
> > not peek at virtio header though...
> > Pls Cc the lists on any discussions in the future.
> >
> > --
> > MST
>
> Sorry I missed reply all. :(
>
> Shirley
^ permalink raw reply
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-01 21:24 UTC (permalink / raw)
To: Shirley Ma
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <1296594585.26937.817.camel@localhost.localdomain>
On Tue, Feb 01, 2011 at 01:09:45PM -0800, Shirley Ma wrote:
> On Mon, 2011-01-31 at 17:30 -0800, Sridhar Samudrala wrote:
> > Yes. It definitely should be 'out'. 'in' should be 0 in the tx path.
> >
> > I tried a simpler version of this patch without any tunables by
> > delaying the signaling until we come out of the for loop.
> > It definitely reduced the number of vmexits significantly for small
> > message
> > guest to host stream test and the throughput went up a little.
> >
> > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> > index 9b3ca10..5f9fae9 100644
> > --- a/drivers/vhost/net.c
> > +++ b/drivers/vhost/net.c
> > @@ -197,7 +197,7 @@ static void handle_tx(struct vhost_net *net)
> > if (err != len)
> > pr_debug("Truncated TX packet: "
> > " len %d != %zd\n", err, len);
> > - vhost_add_used_and_signal(&net->dev, vq, head, 0);
> > + vhost_add_used(vq, head, 0);
> > total_len += len;
> > if (unlikely(total_len >= VHOST_NET_WEIGHT)) {
> > vhost_poll_queue(&vq->poll);
> > @@ -205,6 +205,8 @@ static void handle_tx(struct vhost_net *net)
> > }
> > }
> >
> > + if (total_len > 0)
> > + vhost_signal(&net->dev, vq);
> > mutex_unlock(&vq->mutex);
> > }
>
> Reducing the signaling will reduce the CPU utilization by reducing VM
> exits.
>
> The small message BW is a problem we have seen faster guest/slow vhost,
> even I increased VHOST_NET_WEIGHT times, it didn't help that much for
> BW. For large message size, vhost is able to process all packets on
> time. I played around with guest/host codes, I only see huge BW
> improvement by dropping packets on guest side so far.
>
> Thanks
> Shirley
My theory is that the issue is not signalling.
Rather, our queue fills up, then host handles
one packet and sends an interrupt, and we
immediately wake the queue. So the vq
once it gets full, stays full.
If you try my patch with bufs threshold set to e.g.
half the vq, what we will do is send interrupt after we have processed
half the vq. So host has half the vq to go, and guest has half the vq
to fill.
See?
--
MST
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-01 21:28 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: David Miller, steved, netdev, kvm
In-Reply-To: <20110201212110.GC30770@redhat.com>
On Tue, 2011-02-01 at 23:21 +0200, Michael S. Tsirkin wrote:
> Confused. We compare capacity to skb frags, no?
> That's sg I think ...
Current guest kernel use indirect buffers, num_free returns how many
available descriptors not skb frags. So it's wrong here.
Shirley
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-01 21:32 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <20110201212411.GD30770@redhat.com>
On Tue, 2011-02-01 at 23:24 +0200, Michael S. Tsirkin wrote:
> My theory is that the issue is not signalling.
> Rather, our queue fills up, then host handles
> one packet and sends an interrupt, and we
> immediately wake the queue. So the vq
> once it gets full, stays full.
>From the printk debugging output, it might not be exactly the case. The
ring gets full, run a bit, then gets full, then run a bit, then full...
> If you try my patch with bufs threshold set to e.g.
> half the vq, what we will do is send interrupt after we have processed
> half the vq. So host has half the vq to go, and guest has half the vq
> to fill.
>
> See?
I am cleaning up my set up to run your patch ...
Shirley
^ permalink raw reply
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-01 21:41 UTC (permalink / raw)
To: Shirley Ma; +Cc: David Miller, steved, netdev, kvm, rusty
In-Reply-To: <1296595725.26937.819.camel@localhost.localdomain>
On Tue, Feb 01, 2011 at 01:28:45PM -0800, Shirley Ma wrote:
> On Tue, 2011-02-01 at 23:21 +0200, Michael S. Tsirkin wrote:
> > Confused. We compare capacity to skb frags, no?
> > That's sg I think ...
>
> Current guest kernel use indirect buffers, num_free returns how many
> available descriptors not skb frags. So it's wrong here.
>
> Shirley
I see. Good point. In other words when we complete the buffer
it was indirect, but when we add a new one we
can not allocate indirect so we consume.
And then we start the queue and add will fail.
I guess we need some kind of API to figure out
whether the buf we complete was indirect?
Another failure mode is when skb_xmit_done
wakes the queue: it might be too early, there
might not be space for the next packet in the vq yet.
A solution might be to keep some kind of pool
around for indirect, we wanted to do it for block anyway ...
--
MST
^ permalink raw reply
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-01 21:42 UTC (permalink / raw)
To: Shirley Ma
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <1296595955.26937.822.camel@localhost.localdomain>
On Tue, Feb 01, 2011 at 01:32:35PM -0800, Shirley Ma wrote:
> On Tue, 2011-02-01 at 23:24 +0200, Michael S. Tsirkin wrote:
> > My theory is that the issue is not signalling.
> > Rather, our queue fills up, then host handles
> > one packet and sends an interrupt, and we
> > immediately wake the queue. So the vq
> > once it gets full, stays full.
>
> >From the printk debugging output, it might not be exactly the case. The
> ring gets full, run a bit, then gets full, then run a bit, then full...
Yes, but does it get even half empty in between?
> > If you try my patch with bufs threshold set to e.g.
> > half the vq, what we will do is send interrupt after we have processed
> > half the vq. So host has half the vq to go, and guest has half the vq
> > to fill.
> >
> > See?
>
> I am cleaning up my set up to run your patch ...
>
> Shirley
>
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-01 21:53 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <20110201214211.GB31105@redhat.com>
On Tue, 2011-02-01 at 23:42 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 01, 2011 at 01:32:35PM -0800, Shirley Ma wrote:
> > On Tue, 2011-02-01 at 23:24 +0200, Michael S. Tsirkin wrote:
> > > My theory is that the issue is not signalling.
> > > Rather, our queue fills up, then host handles
> > > one packet and sends an interrupt, and we
> > > immediately wake the queue. So the vq
> > > once it gets full, stays full.
> >
> > >From the printk debugging output, it might not be exactly the case.
> The
> > ring gets full, run a bit, then gets full, then run a bit, then
> full...
>
> Yes, but does it get even half empty in between?
Sometimes, most of them not half of empty in between. But printk slow
down the traffics, so it's not accurate. I think your patch will improve
the performance if it signals guest when half of the ring size is
empty.
But you manage signal by using TX bytes, I would like to change it to
half of the ring size instead for signaling. Is that OK?
Shirley
^ permalink raw reply
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-01 21:56 UTC (permalink / raw)
To: Shirley Ma
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <1296597185.26937.829.camel@localhost.localdomain>
On Tue, Feb 01, 2011 at 01:53:05PM -0800, Shirley Ma wrote:
> On Tue, 2011-02-01 at 23:42 +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 01, 2011 at 01:32:35PM -0800, Shirley Ma wrote:
> > > On Tue, 2011-02-01 at 23:24 +0200, Michael S. Tsirkin wrote:
> > > > My theory is that the issue is not signalling.
> > > > Rather, our queue fills up, then host handles
> > > > one packet and sends an interrupt, and we
> > > > immediately wake the queue. So the vq
> > > > once it gets full, stays full.
> > >
> > > >From the printk debugging output, it might not be exactly the case.
> > The
> > > ring gets full, run a bit, then gets full, then run a bit, then
> > full...
> >
> > Yes, but does it get even half empty in between?
>
> Sometimes, most of them not half of empty in between. But printk slow
> down the traffics, so it's not accurate. I think your patch will improve
> the performance if it signals guest when half of the ring size is
> empty.
>
> But you manage signal by using TX bytes,
There are flags for bytes, buffers and packets.
Try playing with any one of them :)
Just be sure to use v2.
>I would like to change it to
> half of the ring size instead for signaling. Is that OK?
>
> Shirley
>
>
Sure that is why I made it a parameter so you can experiment.
--
MST
^ permalink raw reply
* Re: [PATCH net-2.6] bnx2x: multicasts in NPAR mode
From: David Miller @ 2011-02-01 22:05 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <201102011257.11610.vladz@broadcom.com>
From: "Vlad Zolotarov" <vladz@broadcom.com>
Date: Tue, 1 Feb 2011 12:57:10 +0200
> The chip was erroneously configured to accept all multicast frames
> in a normal (none-promisc) rx mode both on the RSS and on the FCoE L2 rings
> when in an NPAR mode. This caused packet duplication for every received multicast
> frame in this mode.
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thanks Vlad.
^ permalink raw reply
* Re: [patch 3/7] [PATCH] net,s390: provide architecture specific NET_SKB_PAD
From: David Miller @ 2011-02-01 22:17 UTC (permalink / raw)
To: frank.blaschka; +Cc: netdev, linux-s390, horsth
In-Reply-To: <20110201081723.562745244@de.ibm.com>
From: frank.blaschka@de.ibm.com
Date: Tue, 01 Feb 2011 09:16:50 +0100
> From: Horst Hartmann <horsth@linux.vnet.ibm.com>
>
> NET_SKB_PAD has been increased from 32 to 64 and later to max(32, L1_CACHE_BYTES).
> This led to a 25% throughput decrease for streaming workloads accompanied by a
> 37% CPU cost increase on s390.
> In order to fix this provide an architecture specific NET_SKB_PAD config symbol.
>
> Signed-off-by: Horst Hartmann <horsth@linux.vnet.ibm.com>
> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Define it in your arch specific header file like it is designed to
be overridden.
Also, even if this Kconfig thing was the right thing to do, you would
need to put a default for it generically in init/Kconfig or
lib/Kconfig or similar. As this is where the central documentation
for the knob would be placed.
Lastly, you failed in your commit message to describe why you wanted
to use this whacky Kconfig mechanism to override instead of using
a straight CPP define in the s390 headers.
You're modifying generic code, so you better explain what you're doing
and exactly why.
I'm not applying this series until you fix up this change, resubmit
the entire series when you have this stuff fixed up.
Thanks.
^ permalink raw reply
* Re: [PATCH] isdn: icn: Fix potentially wrong string handling
From: David Miller @ 2011-02-01 22:18 UTC (permalink / raw)
To: weil; +Cc: isdn, tj, rostedt, netdev, linux-kernel
In-Reply-To: <1296419486-5482-1-git-send-email-weil@mail.berlios.de>
From: Stefan Weil <weil@mail.berlios.de>
Date: Sun, 30 Jan 2011 21:31:26 +0100
> This warning was reported by cppcheck:
> drivers/isdn/icn/icn.c:1641: error: Dangerous usage of 'rev' (strncpy doesn't always 0-terminate it)
>
> If strncpy copied 20 bytes, the destination string rev was not terminated.
> The patch adds one more byte to rev and makes sure that this byte is
> always 0.
>
> Cc: Karsten Keil <isdn@linux-pingi.de>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Applied, thanks.
^ permalink raw reply
* AVB support (IEEE802.1 audio/video bridging)
From: Eliot Blennerhassett @ 2011-02-01 22:47 UTC (permalink / raw)
To: netdev
Grettings,
before I go into any details, please tell me if this is the right place
to enquire/discuss if/how linux network stacks can support the various
protocols required by AVB
To quote the introduction from wikipedia [1]
"Audio Video Bridging (AVB) is a common name for the set of standards in
development by the IEEE 802.1 Audio Video Bridging Task Group. The
charter of this organization is to "provide the specifications that will
allow time-synchronized low latency streaming services through IEEE 802
networks"."
regards
--
Eliot Blennerhassett
AudioScience Inc.
[1] http://en.wikipedia.org/wiki/Audio_Video_Bridging
^ 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