* Re: [PATCH v2 2/2] iproute2: use libgenl in ipl2tp
From: Julian Anastasov @ 2012-09-11 20:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20120911090908.605d1fbe@nehalam.linuxnetplumber.net>
Hello,
On Tue, 11 Sep 2012, Stephen Hemminger wrote:
> On Tue, 11 Sep 2012 12:04:34 +0300
> Julian Anastasov <ja@ssi.bg> wrote:
>
> > Use the common code from libgenl.c to parse family.
> >
> > Signed-off-by: Julian Anastasov <ja@ssi.bg>
>
> I applied these two but made some modifications:
> 1. change to GENL_INITIALIZER
> 2. use GENL_INITIALIZER
I used 2 defines, so that in tcp_metrics.c I can
use different initialization depending on the command.
But as the structure is unnamed may be it is better to have
single define (both defines merged as you proposed) and
later just to update cmd and flags if needed.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH NEXT] rtlwifi: rtl8192c: rtl8192ce: Add support for B-CUT version of RTL8188CE
From: Larry Finger @ 2012-09-11 20:06 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev, Anisse Astier, Li Chaoming
Realtek devices with designation RTL8188CE-VL have the so-called B-cut
of the wireless chip. This patch adds the special programming needed by
these devices.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Anisse Astier <anisse@astier.eu>
Cc: Li Chaoming <chaoming_li@realsil.com.cn>
---
drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c | 21 +++++++
drivers/net/wireless/rtlwifi/rtl8192ce/def.h | 3 +
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 61 ++++++++++++++++++--
drivers/net/wireless/rtlwifi/rtl8192ce/phy.c | 4 +-
drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 6 +-
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 4 +-
6 files changed, 87 insertions(+), 12 deletions(-)
---
John,
This patch has the patch entitled "rtlwifi: rtl8192ce: Log message that
B_CUT device may not work" as a pre-requisite. Unlike the previous patch,
this one is too invasive to backport to the stable kernels, thus it should
be applied to 3.7.
Thanks,
Larry
---
diff --git a/drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c b/drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c
index cdcad7d..6ae2268 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c
@@ -724,6 +724,26 @@ u8 rtl92c_phy_sw_chnl(struct ieee80211_hw *hw)
}
EXPORT_SYMBOL(rtl92c_phy_sw_chnl);
+static void _rtl92c_phy_sw_rf_setting(struct ieee80211_hw *hw, u8 channel)
+{
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
+ struct rtl_phy *rtlphy = &(rtlpriv->phy);
+ struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
+
+ if (IS_81xxC_VENDOR_UMC_B_CUT(rtlhal->version)) {
+ if (channel == 6 && rtlphy->current_chan_bw ==
+ HT_CHANNEL_WIDTH_20)
+ rtl_set_rfreg(hw, RF90_PATH_A, RF_RX_G1, MASKDWORD,
+ 0x00255);
+ else{
+ u32 backupRF0x1A = (u32)rtl_get_rfreg(hw, RF90_PATH_A,
+ RF_RX_G1, RFREG_OFFSET_MASK);
+ rtl_set_rfreg(hw, RF90_PATH_A, RF_RX_G1, MASKDWORD,
+ backupRF0x1A);
+ }
+ }
+}
+
static bool _rtl92c_phy_set_sw_chnl_cmdarray(struct swchnlcmd *cmdtable,
u32 cmdtableidx, u32 cmdtablesz,
enum swchnlcmd_id cmdid,
@@ -837,6 +857,7 @@ bool _rtl92c_phy_sw_chnl_step_by_step(struct ieee80211_hw *hw,
currentcmd->para1,
RFREG_OFFSET_MASK,
rtlphy->rfreg_chnlval[rfpath]);
+ _rtl92c_phy_sw_rf_setting(hw, channel);
}
break;
default:
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/def.h b/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
index 2925094..3cfa1bb 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
@@ -116,6 +116,9 @@
LE_BITS_TO_4BYTE(((__pcmdfbhdr) + 4), 20, 12)
#define CHIP_VER_B BIT(4)
+#define CHIP_BONDING_IDENTIFIER(_value) (((_value) >> 22) & 0x3)
+#define CHIP_BONDING_92C_1T2R 0x1
+#define RF_TYPE_1T2R BIT(1)
#define CHIP_92C_BITMASK BIT(0)
#define CHIP_UNKNOWN BIT(7)
#define CHIP_92C_1T2R 0x03
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
index 86d73b3..bae5269 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -896,7 +896,6 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
struct rtl_phy *rtlphy = &(rtlpriv->phy);
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
- static bool iqk_initialized; /* initialized to false */
bool rtstatus = true;
bool is92c;
int err;
@@ -921,9 +920,28 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
rtlhal->last_hmeboxnum = 0;
rtl92c_phy_mac_config(hw);
+ /* because last function modify RCR, so we update
+ * rcr var here, or TP will unstable for receive_config
+ * is wrong, RX RCR_ACRC32 will cause TP unstabel & Rx
+ * RCR_APP_ICV will cause mac80211 unassoc for cisco 1252*/
+ rtlpci->receive_config = rtl_read_dword(rtlpriv, REG_RCR);
+ rtlpci->receive_config &= ~(RCR_ACRC32 | RCR_AICV);
+ rtl_write_dword(rtlpriv, REG_RCR, rtlpci->receive_config);
rtl92c_phy_bb_config(hw);
rtlphy->rf_mode = RF_OP_BY_SW_3WIRE;
rtl92c_phy_rf_config(hw);
+ if (IS_VENDOR_UMC_A_CUT(rtlhal->version) &&
+ !IS_92C_SERIAL(rtlhal->version)) {
+ rtl_set_rfreg(hw, RF90_PATH_A, RF_RX_G1, MASKDWORD, 0x30255);
+ rtl_set_rfreg(hw, RF90_PATH_A, RF_RX_G2, MASKDWORD, 0x50a00);
+ } else if (IS_81xxC_VENDOR_UMC_B_CUT(rtlhal->version)) {
+ rtl_set_rfreg(hw, RF90_PATH_A, 0x0C, MASKDWORD, 0x894AE);
+ rtl_set_rfreg(hw, RF90_PATH_A, 0x0A, MASKDWORD, 0x1AF31);
+ rtl_set_rfreg(hw, RF90_PATH_A, RF_IPA, MASKDWORD, 0x8F425);
+ rtl_set_rfreg(hw, RF90_PATH_A, RF_SYN_G2, MASKDWORD, 0x4F200);
+ rtl_set_rfreg(hw, RF90_PATH_A, RF_RCK1, MASKDWORD, 0x44053);
+ rtl_set_rfreg(hw, RF90_PATH_A, RF_RCK2, MASKDWORD, 0x80201);
+ }
rtlphy->rfreg_chnlval[0] = rtl_get_rfreg(hw, (enum radio_path)0,
RF_CHNLBW, RFREG_OFFSET_MASK);
rtlphy->rfreg_chnlval[1] = rtl_get_rfreg(hw, (enum radio_path)1,
@@ -945,11 +963,11 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
if (ppsc->rfpwr_state == ERFON) {
rtl92c_phy_set_rfpath_switch(hw, 1);
- if (iqk_initialized) {
+ if (rtlphy->iqk_initialized) {
rtl92c_phy_iq_calibrate(hw, true);
} else {
rtl92c_phy_iq_calibrate(hw, false);
- iqk_initialized = true;
+ rtlphy->iqk_initialized = true;
}
rtl92c_dm_check_txpower_tracking(hw);
@@ -1004,6 +1022,13 @@ static enum version_8192c _rtl92ce_read_chip_version(struct ieee80211_hw *hw)
? CHIP_VENDOR_UMC_B_CUT : CHIP_UNKNOWN) |
CHIP_VENDOR_UMC));
}
+ if (IS_92C_SERIAL(version)) {
+ value32 = rtl_read_dword(rtlpriv, REG_HPON_FSM);
+ version = (enum version_8192c)(version |
+ ((CHIP_BONDING_IDENTIFIER(value32)
+ == CHIP_BONDING_92C_1T2R) ?
+ RF_TYPE_1T2R : 0));
+ }
}
switch (version) {
@@ -1019,12 +1044,30 @@ static enum version_8192c _rtl92ce_read_chip_version(struct ieee80211_hw *hw)
case VERSION_A_CHIP_88C:
versionid = "A_CHIP_88C";
break;
+ case VERSION_NORMAL_UMC_CHIP_92C_1T2R_A_CUT:
+ versionid = "A_CUT_92C_1T2R";
+ break;
+ case VERSION_NORMAL_UMC_CHIP_92C_A_CUT:
+ versionid = "A_CUT_92C";
+ break;
+ case VERSION_NORMAL_UMC_CHIP_88C_A_CUT:
+ versionid = "A_CUT_88C";
+ break;
+ case VERSION_NORMAL_UMC_CHIP_92C_1T2R_B_CUT:
+ versionid = "B_CUT_92C_1T2R";
+ break;
+ case VERSION_NORMAL_UMC_CHIP_92C_B_CUT:
+ versionid = "B_CUT_92C";
+ break;
+ case VERSION_NORMAL_UMC_CHIP_88C_B_CUT:
+ versionid = "B_CUT_88C";
+ break;
default:
versionid = "Unknown. Bug?";
break;
}
- RT_TRACE(rtlpriv, COMP_INIT, DBG_TRACE,
+ RT_TRACE(rtlpriv, COMP_INIT, DBG_EMERG,
"Chip Version ID: %s\n", versionid);
switch (version & 0x3) {
@@ -1197,6 +1240,7 @@ static void _rtl92ce_poweroff_adapter(struct ieee80211_hw *hw)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_pci_priv *rtlpcipriv = rtl_pcipriv(hw);
+ struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
u8 u1b_tmp;
u32 u4b_tmp;
@@ -1225,7 +1269,8 @@ static void _rtl92ce_poweroff_adapter(struct ieee80211_hw *hw)
rtl_write_word(rtlpriv, REG_GPIO_IO_SEL, 0x0790);
rtl_write_word(rtlpriv, REG_LEDCFG0, 0x8080);
rtl_write_byte(rtlpriv, REG_AFE_PLL_CTRL, 0x80);
- rtl_write_byte(rtlpriv, REG_SPS0_CTRL, 0x23);
+ if (!IS_81xxC_VENDOR_UMC_B_CUT(rtlhal->version))
+ rtl_write_byte(rtlpriv, REG_SPS0_CTRL, 0x23);
if (rtlpcipriv->bt_coexist.bt_coexistence) {
u4b_tmp = rtl_read_dword(rtlpriv, REG_AFE_XTAL_CTRL);
u4b_tmp |= 0x03824800;
@@ -1254,6 +1299,9 @@ void rtl92ce_card_disable(struct ieee80211_hw *hw)
rtlpriv->cfg->ops->led_control(hw, LED_CTL_POWER_OFF);
RT_SET_PS_LEVEL(ppsc, RT_RF_OFF_LEVL_HALT_NIC);
_rtl92ce_poweroff_adapter(hw);
+
+ /* after power off we should do iqk again */
+ rtlpriv->phy.iqk_initialized = false;
}
void rtl92ce_interrupt_recognized(struct ieee80211_hw *hw,
@@ -1912,6 +1960,8 @@ static void rtl92ce_update_hal_rate_mask(struct ieee80211_hw *hw,
ratr_bitmap &= 0x0f0ff0ff;
break;
}
+ sta_entry->ratr_index = ratr_index;
+
RT_TRACE(rtlpriv, COMP_RATR, DBG_DMESG,
"ratr_bitmap :%x\n", ratr_bitmap);
*(u32 *)&rate_mask = (ratr_bitmap & 0x0fffffff) |
@@ -2291,3 +2341,4 @@ void rtl92ce_suspend(struct ieee80211_hw *hw)
void rtl92ce_resume(struct ieee80211_hw *hw)
{
}
+
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c b/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c
index 88deae6..a66ba97 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c
@@ -82,7 +82,9 @@ bool rtl92c_phy_mac_config(struct ieee80211_hw *hw)
if (is92c)
rtl_write_byte(rtlpriv, 0x14, 0x71);
- return rtstatus;
+ else
+ rtl_write_byte(rtlpriv, 0x04CA, 0x0A);
+ return rtstatus;
}
bool rtl92c_phy_bb_config(struct ieee80211_hw *hw)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
index ea2e1bd..60451ee 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
@@ -162,12 +162,10 @@ int rtl92c_init_sw_vars(struct ieee80211_hw *hw)
/* request fw */
if (IS_VENDOR_UMC_A_CUT(rtlhal->version) &&
- !IS_92C_SERIAL(rtlhal->version)) {
+ !IS_92C_SERIAL(rtlhal->version))
rtlpriv->cfg->fw_name = "rtlwifi/rtl8192cfwU.bin";
- } else if (IS_81xxC_VENDOR_UMC_B_CUT(rtlhal->version)) {
+ else if (IS_81xxC_VENDOR_UMC_B_CUT(rtlhal->version))
rtlpriv->cfg->fw_name = "rtlwifi/rtl8192cfwU_B.bin";
- pr_info("****** This B_CUT device may not work with kernels 3.6 and earlier\n");
- }
rtlpriv->max_fw_size = 0x4000;
pr_info("Using firmware %s\n", rtlpriv->cfg->fw_name);
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
index 390d6d4..b8a3c03 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
@@ -127,11 +127,11 @@ static void _rtl92ce_query_rxphystatus(struct ieee80211_hw *hw,
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct phy_sts_cck_8192s_t *cck_buf;
+ struct rtl_ps_ctl *ppsc = rtl_psc(rtlpriv);
s8 rx_pwr_all = 0, rx_pwr[4];
u8 evm, pwdb_all, rf_rx_num = 0;
u8 i, max_spatial_stream;
u32 rssi, total_rssi = 0;
- bool in_powersavemode = false;
bool is_cck_rate;
is_cck_rate = RX_HAL_IS_CCK_RATE(pdesc);
@@ -147,7 +147,7 @@ static void _rtl92ce_query_rxphystatus(struct ieee80211_hw *hw,
u8 report, cck_highpwr;
cck_buf = (struct phy_sts_cck_8192s_t *)p_drvinfo;
- if (!in_powersavemode)
+ if (ppsc->rfpwr_state == ERFON)
cck_highpwr = (u8) rtl_get_bbreg(hw,
RFPGA0_XA_HSSIPARAMETER2,
BIT(9));
--
1.7.10.4
^ permalink raw reply related
* RE: GRO aggregation
From: Eric Dumazet @ 2012-09-11 19:35 UTC (permalink / raw)
To: Shlomo Pongratz; +Cc: netdev@vger.kernel.org
In-Reply-To: <36F7E4A28C18BE4DB7C86058E7B607241E622083@MTRDAG01.mtl.com>
On Tue, 2012-09-11 at 19:24 +0000, Shlomo Pongratz wrote:
>
> I see that in ixgbe the weight for the NAPI is 64 (netif_napi_add). So
> if packets are arriving in high rate then an the CPU is fast enough to
> collect the packets as they arrive, assuming packets continue to
> arrives while the NAPI runs. Then it should have aggregate more. So we
> will have less passes trough the stack.
>
As I said, _if_ your cpu was loaded by other stuff, then you would see
biggest GRO packets.
GRO is not : "We want to kill latency and have big packets just because
its better"
Its more like : If load is big enough, try to aggregate TCP frames in
less skbs.
^ permalink raw reply
* Re: GRO aggregation
From: David Miller @ 2012-09-11 19:35 UTC (permalink / raw)
To: shlomop; +Cc: eric.dumazet, netdev
In-Reply-To: <36F7E4A28C18BE4DB7C86058E7B607241E622083@MTRDAG01.mtl.com>
From: Shlomo Pongratz <shlomop@mellanox.com>
Date: Tue, 11 Sep 2012 19:24:26 +0000
> I see that in ixgbe the weight for the NAPI is 64
> (netif_napi_add). So if packets are arriving in high rate then an
> the CPU is fast enough to collect the packets as they arrive,
> assuming packets continue to arrives while the NAPI runs. Then it
> should have aggregate more. So we will have less passes trough the
> stack.
Eric is trying to say that that cpu is fast enough that it completely
depletes the pending RX packets, the RX queue is empty, and there is
only 32K worth of GRO to accumulate.
BTW, your email quoting is non-standard and very confusing. There
is absolutely no delineation between the text that you are writing
and the text of the people you are responding too. Please learn how
to write email replies properly.
Thank you.
^ permalink raw reply
* RE: GRO aggregation
From: Shlomo Pongratz @ 2012-09-11 19:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1347390113.13103.660.camel@edumazet-glaptop>
From: Eric Dumazet [eric.dumazet@gmail.com]
Sent: Tuesday, September 11, 2012 10:02 PM
To: Shlomo Pongratz
Cc: netdev@vger.kernel.org
Subject: RE: GRO aggregation
On Tue, 2012-09-11 at 18:49 +0000, Shlomo Pongratz wrote:
> I disabled the LRO. I actually tried the all the 4 options and found that LRO, GRO, LRO+GRO gives the same results for ixgbe w.r.t aggregation size (didn't check for throughput or latency).
> Is there a timeout that flushes the aggregated SKBs before 64K were aggregated?
At the end of NAPI run, we flush the gro state.
It basically means that an interrupt came, and we fetched 21 frames from
the NIC.
To get more packets per interrupt, you might try to slow down your
cpu ;)
But I dont get the point.
I see that in ixgbe the weight for the NAPI is 64 (netif_napi_add). So if packets are arriving in high rate then an the CPU is fast enough to collect the packets as they arrive, assuming packets continue to arrives while the NAPI runs. Then it should have aggregate more. So we will have less passes trough the stack.
Shlomo
^ permalink raw reply
* Re: NIC emulation with built-in rate limiting?
From: Gregory Carter @ 2012-09-11 19:05 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev, kvm, Lee Schermerhorn, Brian Haley
In-Reply-To: <504F7DCB.3050401@hp.com>
You can not model TCP/IP accurately in a KVM VM environment.
Too much background machinations are going on to make that plausible.
I would use a small network with actual hardware for the testing model.
You will have to use the actual gear in place and test and tweak there
if you are doing bandwidth sharing, multi-channel with qdiscs stochastic
queuing.
However, you can model various protocols using single channel qdiscs
fairly well, certainly well enough to use the data to direct your build
outs.
Application behavior works pretty well, if you are simply limiting
bandwidth sharing using single channel qdiscs such as discovering lower
end acceptable transmission rates for VoIP traffic etc. I have had
really good success with various codecs tested with single channel rate
limited qdiscs to answer various questions about latency and
bandwidth/quality issues in transmission of audio/video, yielding
numbers that reveal useful behavior in the design planning phases of
network services.
May I suggest allocating one channel to one qdisc.
Also, you have to strip the machine down if you want accurate results.
Do not have X running or anything other than the virtual machines
required as part of your testing process. Strip the process queue on
the testing gear to only running the VM's and Virtual network in question.
The lower you go in the network VM's connections, the more chaotic and
useless your numbers are going to be. In certain situations, if you
strip your test bed down far enough, you can predict how certain kernel
processes will affect your monitoring and screen those out of the data sets.
I use stripped down source built kernels by the way for many of these
questions because a lot of junk in the kernel such as I/O queing and
scheduling I turn off, specifically building kernels for running complex
VM point to point virtualized networks with as little background noise
as I can get.
After a while, if you standardize your network setup, you can screen out
a lot of background noise, and get some useful answers to how
applications and limited bandwidth connected endpoints will fair.
-gc
On 09/11/2012 01:07 PM, Rick Jones wrote:
> Are there NIC emulations in the kernel with built-in rate limiting?
> Or is that supposed to be strictly the province of qdiscs/filters?
>
> I've been messing about with netperf in a VM using virtio_net, to
> which rate limiting has been applied to its corresponding vnetN
> interface - rate policing on vnetN ingress (the VM's outbound) and htb
> on the vnetN egress (the VM's inbound).
>
> Looking at the "demo mode" output of netperf and a VM throttled to 800
> Mbit/s in each direction I see that inbound to the VM is quite steady
> over time - right at about 800 Mbit/s. However, looking at that same
> sort of data for outbound from the VM shows considerable variability
> ranging anywhere from 700 to 900 Mbit/s (though the bulk of the
> variability is clustered more like 750 to 850.
>
> I was thinking that part of the reason may stem from the lack of
> direct feedback to the VM since the policing is on the vnetN interface
> and wondered if it might be "better" if the VM's outbound network rate
> were constrained not by an ingress policing filter on the vnetN
> interface but by the host/hypervisor/emulator portion of the NIC and
> how quickly it pulls packets from the tx queue. That would allow the
> queue which built-up to be in the VM itself and would more accurately
> represent what a "real NIC" of that bandwidth would do.
>
> happy benchmarking,
>
> rick jones
> --
> 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: GRO aggregation
From: Eric Dumazet @ 2012-09-11 19:01 UTC (permalink / raw)
To: Shlomo Pongratz; +Cc: netdev@vger.kernel.org
In-Reply-To: <36F7E4A28C18BE4DB7C86058E7B607241E622022@MTRDAG01.mtl.com>
On Tue, 2012-09-11 at 18:49 +0000, Shlomo Pongratz wrote:
> I disabled the LRO. I actually tried the all the 4 options and found that LRO, GRO, LRO+GRO gives the same results for ixgbe w.r.t aggregation size (didn't check for throughput or latency).
> Is there a timeout that flushes the aggregated SKBs before 64K were aggregated?
At the end of NAPI run, we flush the gro state.
It basically means that an interrupt came, and we fetched 21 frames from
the NIC.
To get more packets per interrupt, you might try to slow down your
cpu ;)
But I dont get the point.
^ permalink raw reply
* e1000e: Disabling IRQ #57 .. machine dies
From: Cristian Rodríguez @ 2012-09-11 18:50 UTC (permalink / raw)
To: Netdev
Hi:
In current linus tree, in a machine using the e1000e driver
hwinfo --netcard
22: PCI 400.0: 0200 Ethernet controller
[Created at pci.319]
Unique ID: rBUF.cuT2KaC3ZS1
Parent ID: HnsE.Z52SDLRIaH2
SysFS ID: /devices/pci0000:00/0000:00:1c.5/0000:04:00.0
SysFS BusID: 0000:04:00.0
Hardware Class: network
Model: "Intel 82574L Gigabit Network Connection"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x10d3 "82574L Gigabit Network Connection"
SubVendor: pci 0x1043 "ASUSTeK Computer Inc."
SubDevice: pci 0x8369
Driver: "e1000e"
Driver Modules: "e1000e"
Device File: eth0
Memory Range: 0xf7d00000-0xf7d1ffff (rw,non-prefetchable)
I/O Ports: 0xd000-0xdfff (rw)
Memory Range: 0xf7d20000-0xf7d23fff (rw,non-prefetchable)
IRQ: 17 (no events)
Link detected: yes
Module Alias: "pci:v00008086d000010D3sv00001043sd00008369bc02sc00i00"
Driver Info #0:
Driver Status: e1000e is active
Driver Activation Cmd: "modprobe e1000e"
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #15 (PCI bridge)
cat /proc/interrupts
57 IR-PCI-MSI-edge eth0
the driver works after a while, but then a single message
"Disabling IRQ #57"
is sent to the console and the machine dies, nothing else is written in
the logs and remote ikvm becames unresponsive so there is no way to
bring more debug info back.. kernel 3.5.3 works ok.
Anyone else seeing this ?
^ permalink raw reply
* RE: GRO aggregation
From: Shlomo Pongratz @ 2012-09-11 18:51 UTC (permalink / raw)
To: mleitner@redhat.com; +Cc: netdev@vger.kernel.org
In-Reply-To: <504F876D.9020102@redhat.com>
From: Marcelo Ricardo Leitner [mleitner@redhat.com]
Sent: Tuesday, September 11, 2012 9:48 PM
To: Shlomo Pongratz
Cc: netdev@vger.kernel.org
Subject: Re: GRO aggregation
On 09/11/2012 03:41 PM, Shlomo Pongratz wrote:
> From: Marcelo Ricardo Leitner [mleitner@redhat.com]
> Sent: Tuesday, September 11, 2012 9:20 PM
> To: Shlomo Pongratz
> Cc: netdev@vger.kernel.org
> Subject: Re: GRO aggregation
>
> On 09/11/2012 10:45 AM, Shlomo Pongartz wrote:
>> Hi,
>>
>> I’m checking GRO aggregation with kernel 3.6.0-rc1+ using Intel ixgbe
>> driver.
>> The mtu is 1500 and GRO is on and so are SG and RX checksum.
>> I ran iperf with default setting and monitor the receiver with tcpdump.
>> The tcpdump shows that the maximal aggregation is 32120 which is 21 * 1500.
>> In the transmitter side tcpdump shows that TSO works better (~64K).
>> I did a capture without GRO enabled to see if there was a difference
>> between any flag
>> of any two consecutive packets that forced flushing but didn't find
>> anything.
>> Is the GRO aggregation can be tuned.
>
> Hi Shlomo,
>
> Have you tried tuning coalescing parameters?
>
> Marcelo
>
>
> Hi Marcelo
>
> I didn't play with interrupts coalescing.
> Do you suggest to increase the value?
Actually it was an idea from top of my mind, I don't know how it applies
to ixgbe, sorry. But making the NIC hold the packets a bit more should
make it send larger ones to kernel. Trade-off between latency/throughput.
I was thinking about ethtool -c options, like rx-usecs*
Marcelo
I'll try to play with it a little.
Thanks.
Shlomo
^ permalink raw reply
* RE: GRO aggregation
From: Shlomo Pongratz @ 2012-09-11 18:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1347388396.13103.658.camel@edumazet-glaptop>
From: Eric Dumazet [eric.dumazet@gmail.com]
Sent: Tuesday, September 11, 2012 9:33 PM
To: Shlomo Pongratz
Cc: netdev@vger.kernel.org
Subject: Re: GRO aggregation
On Tue, 2012-09-11 at 16:45 +0300, Shlomo Pongartz wrote:
> Hi,
>
> I’m checking GRO aggregation with kernel 3.6.0-rc1+ using Intel ixgbe
> driver.
> The mtu is 1500 and GRO is on and so are SG and RX checksum.
> I ran iperf with default setting and monitor the receiver with tcpdump.
> The tcpdump shows that the maximal aggregation is 32120 which is 21 * 1500.
> In the transmitter side tcpdump shows that TSO works better (~64K).
> I did a capture without GRO enabled to see if there was a difference
> between any flag
> of any two consecutive packets that forced flushing but didn't find
> anything.
> Is the GRO aggregation can be tuned.
It might mean NAPI runs while about 21 frames can be fetched at once
from NIC.
If receiver cpu is fast enough, it has no need to aggregate more segment
per skb.
Is LRO off or on ?
GRO itself has a 64Kbytes limit.
Hi Eric.
I disabled the LRO. I actually tried the all the 4 options and found that LRO, GRO, LRO+GRO gives the same results for ixgbe w.r.t aggregation size (didn't check for throughput or latency).
Is there a timeout that flushes the aggregated SKBs before 64K were aggregated?
Shlomo
^ permalink raw reply
* Re: GRO aggregation
From: Marcelo Ricardo Leitner @ 2012-09-11 18:48 UTC (permalink / raw)
To: Shlomo Pongratz; +Cc: netdev@vger.kernel.org
In-Reply-To: <36F7E4A28C18BE4DB7C86058E7B607241E622015@MTRDAG01.mtl.com>
On 09/11/2012 03:41 PM, Shlomo Pongratz wrote:
> From: Marcelo Ricardo Leitner [mleitner@redhat.com]
> Sent: Tuesday, September 11, 2012 9:20 PM
> To: Shlomo Pongratz
> Cc: netdev@vger.kernel.org
> Subject: Re: GRO aggregation
>
> On 09/11/2012 10:45 AM, Shlomo Pongartz wrote:
>> Hi,
>>
>> I’m checking GRO aggregation with kernel 3.6.0-rc1+ using Intel ixgbe
>> driver.
>> The mtu is 1500 and GRO is on and so are SG and RX checksum.
>> I ran iperf with default setting and monitor the receiver with tcpdump.
>> The tcpdump shows that the maximal aggregation is 32120 which is 21 * 1500.
>> In the transmitter side tcpdump shows that TSO works better (~64K).
>> I did a capture without GRO enabled to see if there was a difference
>> between any flag
>> of any two consecutive packets that forced flushing but didn't find
>> anything.
>> Is the GRO aggregation can be tuned.
>
> Hi Shlomo,
>
> Have you tried tuning coalescing parameters?
>
> Marcelo
>
>
> Hi Marcelo
>
> I didn't play with interrupts coalescing.
> Do you suggest to increase the value?
Actually it was an idea from top of my mind, I don't know how it applies
to ixgbe, sorry. But making the NIC hold the packets a bit more should
make it send larger ones to kernel. Trade-off between latency/throughput.
I was thinking about ethtool -c options, like rx-usecs*
Marcelo
^ permalink raw reply
* Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces
From: Love, Robert W @ 2012-09-11 18:47 UTC (permalink / raw)
To: Bhanu Prakash Gollapudi
Cc: Chris Leech, netdev@vger.kernel.org, gregkh@linuxfoundation.org,
linux-scsi@vger.kernel.org, devel@open-fcoe.org
In-Reply-To: <504F836C.3040907@broadcom.com>
On Tue 11 Sep 2012 11:31:08 AM PDT, Bhanu Prakash Gollapudi wrote:
> On 9/11/2012 10:36 AM, Love, Robert W wrote:
>> On Tue 11 Sep 2012 10:06:29 AM PDT, Chris Leech wrote:
>>> On Mon, Sep 10, 2012 at 3:59 PM, Robert Love
>>> <robert.w.love@intel.com> wrote:
>>
>> <snip>
>>
>>>> 1) Create/alloc the port
>>>> - Allocate kernel memory and create per-instance sysfs devices
>>>> - No discovery or login
>>>>
>>
>> # echo eth3.172-fcoe > /sys/bus/fcoe/ctlr_create
>
> I'm assuming the existing functionality of automatically creating the
> vlan interface by fcoemon (using the cfg-ethX) continues to exist and
> the above is not a replacement for fcoeadm -c.
>
Yes, you're right. These examples are only if you were using the
interfaces from BASH. It's all coded up for fcoemon and there shouldn't
be any user experience change with the new code. I'll post that code to
devel@open-fcoe.org once I get it rebased and quickly tested.
>>
>> results in:
>>
>> /sys/bus/fcoe/devices/ctlr_0/
>>
>>>> 2) Configure the port
>>>> - Change mode, set ddp_min, etc...
>>>>
>>
>> # echo "Fabric" > /sys/bus/fcoe/devices/ctlr_0/mode
>>
>> no visible change
>>
>>>> 3) Start the port
>>>> - Begins discovery and/or login (depending on mode)
>>>>
>>
>> # echo 1 > /sys/bus/fcoe/devices/ctlr_0/start
>>
>> Begins discovery and login. Assuming there are FCFs then results in:
>>
>> /sys/bus/fcoe/devices/fcf_0
>
> I'm also assuming that the above three steps can be clubbed by
> fcoeutils, perhaps by adding 'mode' parameter into the cfg-ethX file.
> That way 'service fcoe start' will be no different with the proposed
> model, except that there will be multiple entry points into the driver
> (alloc, config, start) instead of just one (create).
>
Yes, you're right here too. However, the default is 'Fabric' so fcoemon
won't actually have to change the mode. However, I'd like to see VN2VN
support added to fcoeadm/fcoemon. It's on the TODO list. Once that's
implemented fcoemon would need to change the mode depending on the
user's selection.
^ permalink raw reply
* RE: GRO aggregation
From: Shlomo Pongratz @ 2012-09-11 18:41 UTC (permalink / raw)
To: mleitner@redhat.com; +Cc: netdev@vger.kernel.org
In-Reply-To: <504F80DC.7010707@redhat.com>
From: Marcelo Ricardo Leitner [mleitner@redhat.com]
Sent: Tuesday, September 11, 2012 9:20 PM
To: Shlomo Pongratz
Cc: netdev@vger.kernel.org
Subject: Re: GRO aggregation
On 09/11/2012 10:45 AM, Shlomo Pongartz wrote:
> Hi,
>
> I’m checking GRO aggregation with kernel 3.6.0-rc1+ using Intel ixgbe
> driver.
> The mtu is 1500 and GRO is on and so are SG and RX checksum.
> I ran iperf with default setting and monitor the receiver with tcpdump.
> The tcpdump shows that the maximal aggregation is 32120 which is 21 * 1500.
> In the transmitter side tcpdump shows that TSO works better (~64K).
> I did a capture without GRO enabled to see if there was a difference
> between any flag
> of any two consecutive packets that forced flushing but didn't find
> anything.
> Is the GRO aggregation can be tuned.
Hi Shlomo,
Have you tried tuning coalescing parameters?
Marcelo
Hi Marcelo
I didn't play with interrupts coalescing.
Do you suggest to increase the value?
Shlomo
^ permalink raw reply
* Re: GRO aggregation
From: Eric Dumazet @ 2012-09-11 18:33 UTC (permalink / raw)
To: Shlomo Pongartz; +Cc: netdev
In-Reply-To: <504F4063.9030706@mellanox.com>
On Tue, 2012-09-11 at 16:45 +0300, Shlomo Pongartz wrote:
> Hi,
>
> I’m checking GRO aggregation with kernel 3.6.0-rc1+ using Intel ixgbe
> driver.
> The mtu is 1500 and GRO is on and so are SG and RX checksum.
> I ran iperf with default setting and monitor the receiver with tcpdump.
> The tcpdump shows that the maximal aggregation is 32120 which is 21 * 1500.
> In the transmitter side tcpdump shows that TSO works better (~64K).
> I did a capture without GRO enabled to see if there was a difference
> between any flag
> of any two consecutive packets that forced flushing but didn't find
> anything.
> Is the GRO aggregation can be tuned.
It might mean NAPI runs while about 21 frames can be fetched at once
from NIC.
If receiver cpu is fast enough, it has no need to aggregate more segment
per skb.
Is LRO off or on ?
GRO itself has a 64Kbytes limit.
^ permalink raw reply
* Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces
From: Bhanu Prakash Gollapudi @ 2012-09-11 18:31 UTC (permalink / raw)
To: Love, Robert W
Cc: Chris Leech, netdev@vger.kernel.org, gregkh@linuxfoundation.org,
linux-scsi@vger.kernel.org, devel@open-fcoe.org
In-Reply-To: <504F76A1.50809@intel.com>
On 9/11/2012 10:36 AM, Love, Robert W wrote:
> On Tue 11 Sep 2012 10:06:29 AM PDT, Chris Leech wrote:
>> On Mon, Sep 10, 2012 at 3:59 PM, Robert Love <robert.w.love@intel.com> wrote:
>
> <snip>
>
>>> 1) Create/alloc the port
>>> - Allocate kernel memory and create per-instance sysfs devices
>>> - No discovery or login
>>>
>
> # echo eth3.172-fcoe > /sys/bus/fcoe/ctlr_create
I'm assuming the existing functionality of automatically creating the
vlan interface by fcoemon (using the cfg-ethX) continues to exist and
the above is not a replacement for fcoeadm -c.
>
> results in:
>
> /sys/bus/fcoe/devices/ctlr_0/
>
>>> 2) Configure the port
>>> - Change mode, set ddp_min, etc...
>>>
>
> # echo "Fabric" > /sys/bus/fcoe/devices/ctlr_0/mode
>
> no visible change
>
>>> 3) Start the port
>>> - Begins discovery and/or login (depending on mode)
>>>
>
> # echo 1 > /sys/bus/fcoe/devices/ctlr_0/start
>
> Begins discovery and login. Assuming there are FCFs then results in:
>
> /sys/bus/fcoe/devices/fcf_0
I'm also assuming that the above three steps can be clubbed by
fcoeutils, perhaps by adding 'mode' parameter into the cfg-ethX file.
That way 'service fcoe start' will be no different with the proposed
model, except that there will be multiple entry points into the driver
(alloc, config, start) instead of just one (create).
>
>>> 4) Destroy the port
>>> - Logout and free all memory
>
> # echo eth3.172-fcoe > /sys/bus/fcoe/ctlr_destroy
>
> /sys/bus/fcoe/devices/ctlr_0 is removed.
>
>>>
>>> I'm looking for feedback on using sysfs files as control interfaces that
>>> the user (application) would write interface names to. I modeled this
>>> series off of the bonding sysfs interface, but it was suggested to me that
>>> it might not be a good example. I belive bonding uses two values per-file
>>> a '+' or a '-" to add or delete and then the ifname apended. I am simply
>>> writing the ifname to the ctlr_create or ctlr_destroy.
>>
>> Can you give an example session that goes through the 4 steps above
>> and what the sysfs hierarchy looks like at each step? I mostly get it
>> from the patch descriptions, but I think it would help discussion of
>> your proposed interfaces to see an example of them in use.
>>
>
> See above. bash-style.
>
>> This feels a little awkward with all the special control files. Have
>> you thought about something designed for creating kernel objects, like
>> configfs? Similarly the separate start, enable, disable files vs.
>
> Let me do some more reading about configfs. I may not have given it
> enough thought.
>
>> having some sort of status attribute that can take different values.
>> I feel like these need to be rethought as attributes instead of
>> triggers. Is there a big difference between start and enable? Can
>> you achieve the split between create and start by having it come up in
>> a disabled state by default?
>>
>
> It's a good idea. I'll look into it.
>
>> That being said, I'm glad this is being reworked. Do you have any
>> other functionality in mind that this is laying the groundwork for?
>>
>
> I have one feature and a few ideas. I currently have a patch that adds
> a fabric selection feature. I add another RW attribute to the ctlr_X
> device. If the user writes fabric name to the file libfcoe uses it in
> it's FCF selection algorithm. Here's my commit message from that patch.
> I can share the patch if people would like to see it too. The current
> implementation also allows the user to force the login through a
> specific FCF.
>
> libfcoe, bnx2fc, fcoe: Add 'selection' attribute
>
> This patch adds a 'selection' attribute to the
> fcoe_ctlr_device. The user can write either a
> '0x' prefixed fabric name or a ':' separated
> MAC address to this file. If a fabric name is
> provided the fcoe ctlr will only consider FCFs
> with the fabric name when choosing a FCF to login
> to. If a MAC address is provided the initiator
> will only login to a FCF with the given Ethernet
> address. Only one selection is valid at a time.
>
> There are corresponding changes to fcoe-utils
> to take advantage of this kernel feature and
> to make it more accessible for the user.
>
> To accompany this feature I created a new fipfcf application based on
> fipvlan that sends out a discovery solicitation and displays
> advertising FCFs.
>
> I've also been talking with Mark Rustad about doing an 'auto' mode
> where Fabric discovery is attempted first and if it fails then it tries
> VN2VN discovery, but so for we've only had hallway conversations about
> it and nothing has been flushed out.
>
> Thanks, //Rob\x04�{.n�+�������+%��lzwm��b�맲��r��zX��^[\x1c�(��\x17��ܨ}���Ơz�&j:+v���\a����zZ+��+zf���h���~����i���z�\x1e�w���?����&�)ߢ^[f
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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: GRO aggregation
From: Marcelo Ricardo Leitner @ 2012-09-11 18:20 UTC (permalink / raw)
To: Shlomo Pongartz; +Cc: netdev
In-Reply-To: <504F4063.9030706@mellanox.com>
On 09/11/2012 10:45 AM, Shlomo Pongartz wrote:
> Hi,
>
> I’m checking GRO aggregation with kernel 3.6.0-rc1+ using Intel ixgbe
> driver.
> The mtu is 1500 and GRO is on and so are SG and RX checksum.
> I ran iperf with default setting and monitor the receiver with tcpdump.
> The tcpdump shows that the maximal aggregation is 32120 which is 21 * 1500.
> In the transmitter side tcpdump shows that TSO works better (~64K).
> I did a capture without GRO enabled to see if there was a difference
> between any flag
> of any two consecutive packets that forced flushing but didn't find
> anything.
> Is the GRO aggregation can be tuned.
Hi Shlomo,
Have you tried tuning coalescing parameters?
Marcelo
^ permalink raw reply
* Re: [net-next.git 5/8 (V2)] stmmac: get/set coalesce parameters via ethtool
From: Ben Hutchings @ 2012-09-11 18:14 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev, davem
In-Reply-To: <1347346514-23411-6-git-send-email-peppe.cavallaro@st.com>
On Tue, 2012-09-11 at 08:55 +0200, Giuseppe CAVALLARO wrote:
> This patch is to get/set the tx/rx coalesce parameters
> via ethtool interface.
>
> Tests have been done on several platform with
> different GMAC chips w/o w/ RX watchdog feature.
>
> V2: reject coalesce settings that are not supported.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/common.h | 8 ++-
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 +
> .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 85 ++++++++++++++++++++
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 20 +++---
> 4 files changed, 103 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
> index 02eb2da..b9033cc 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
> @@ -169,7 +169,13 @@ struct stmmac_extra_stats {
> #define DMA_HW_FEAT_SAVLANINS 0x08000000 /* Source Addr or VLAN Insertion */
> #define DMA_HW_FEAT_ACTPHYIF 0x70000000 /* Active/selected PHY interface */
> #define DEFAULT_DMA_PBL 8
> -#define DEFAULT_DMA_RIWT 0xff /* Max RI Watchdog Timer count */
> +
> +/* Coalesce defines */
> +#define MAX_DMA_RIWT 0xff /* Max RI Watchdog Timer count */
> +#define MIN_DMA_RIWT 0x20
> +#define STMMAC_COAL_TX_TIMER 40000
> +#define STMMAC_MAX_COAL_TX_TICK 100000
> +#define STMMAC_TX_MAX_FRAMES 32
>
> enum rx_frame_status { /* IPC status */
> good_frame = 0,
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> index 6901e3c..ad4f6b9 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> @@ -93,6 +93,7 @@ struct stmmac_priv {
> u32 tx_count_frames;
> u32 tx_coal_frames;
> u32 tx_coal_timer;
> + u32 rx_riwt;
> };
>
> extern int phyaddr;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> index 48ad0bc..d27cc18 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> @@ -522,6 +522,89 @@ static int stmmac_ethtool_op_set_eee(struct net_device *dev,
> return phy_ethtool_set_eee(priv->phydev, edata);
> }
>
> +static u32 stmmac_usec2riwt(u32 usec, struct stmmac_priv *priv)
> +{
> + unsigned long clk = clk_get_rate(priv->stmmac_clk);
> +
> + if (!clk)
> + return 0;
> +
> + return (usec * (clk / 1000000)) / 256;
> +}
> +
> +static u32 stmmac_riwt2usec(u32 riwt, struct stmmac_priv *priv)
> +{
> + unsigned long clk = clk_get_rate(priv->stmmac_clk);
> +
> + if (!clk)
> + return 0;
> +
> + return (riwt * 256) / (clk / 1000000);
> +}
> +
> +static int stmmac_get_coalesce(struct net_device *dev,
> + struct ethtool_coalesce *ec)
> +{
> + struct stmmac_priv *priv = netdev_priv(dev);
> +
> + ec->tx_coalesce_usecs = priv->tx_coal_timer;
> + ec->tx_max_coalesced_frames = priv->tx_coal_frames;
> +
> + if (priv->use_riwt)
> + ec->rx_coalesce_usecs = stmmac_riwt2usec(priv->rx_riwt, priv);
> +
> + return 0;
> +}
> +
> +static int stmmac_set_coalesce(struct net_device *dev,
> + struct ethtool_coalesce *ec)
> +{
> + struct stmmac_priv *priv = netdev_priv(dev);
> + unsigned int rx_riwt;
> +
> + /* Check not supported parameters */
> + if ((ec->rx_max_coalesced_frames) || (ec->rx_coalesce_usecs_irq) ||
> + (ec->rx_max_coalesced_frames_irq) || (ec->tx_coalesce_usecs_irq) ||
> + (ec->use_adaptive_rx_coalesce) || (ec->use_adaptive_tx_coalesce) ||
> + (ec->pkt_rate_low) || (ec->rx_coalesce_usecs_low) ||
> + (ec->rx_max_coalesced_frames_low) || (ec->tx_coalesce_usecs_high) ||
> + (ec->tx_max_coalesced_frames_low) || (ec->pkt_rate_high) ||
> + (ec->tx_coalesce_usecs_low) || (ec->rx_coalesce_usecs_high) ||
> + (ec->rx_max_coalesced_frames_high) ||
> + (ec->tx_max_coalesced_frames_irq) ||
> + (ec->stats_block_coalesce_usecs) ||
> + (ec->tx_max_coalesced_frames_high) || (ec->rate_sample_interval))
> + return -EOPNOTSUPP;
> +
> + /* No rx interrupts will be generated if both are zero */
> + if (ec->rx_coalesce_usecs == 0)
> + return -EINVAL;
> +
> + /* No tx interrupts will be generated if both are zero */
> + if ((ec->tx_coalesce_usecs == 0) &&
> + (ec->tx_max_coalesced_frames == 0))
> + return -EINVAL;
> +
> + if ((ec->tx_coalesce_usecs > STMMAC_COAL_TX_TIMER) ||
> + (ec->tx_max_coalesced_frames > STMMAC_TX_MAX_FRAMES))
> + return -EINVAL;
> +
> + rx_riwt = stmmac_usec2riwt(ec->rx_coalesce_usecs, priv);
> +
> + if ((rx_riwt > MAX_DMA_RIWT) || (rx_riwt < MIN_DMA_RIWT))
> + return -EINVAL;
> + else if (!priv->use_riwt)
> + return -EOPNOTSUPP;
> +
> + /* Only copy relevant parameters, ignore all others. */
> + priv->tx_coal_frames = ec->tx_max_coalesced_frames;
> + priv->tx_coal_timer = ec->tx_coalesce_usecs;
> + priv->rx_riwt = rx_riwt;
> + priv->hw->dma->rx_watchdog(priv->ioaddr, priv->rx_riwt);
> +
> + return 0;
> +}
> +
> static const struct ethtool_ops stmmac_ethtool_ops = {
> .begin = stmmac_check_if_running,
> .get_drvinfo = stmmac_ethtool_getdrvinfo,
> @@ -542,6 +625,8 @@ static const struct ethtool_ops stmmac_ethtool_ops = {
> .set_eee = stmmac_ethtool_op_set_eee,
> .get_sset_count = stmmac_get_sset_count,
> .get_ts_info = ethtool_op_get_ts_info,
> + .get_coalesce = stmmac_get_coalesce,
> + .set_coalesce = stmmac_set_coalesce,
> };
>
> void stmmac_set_ethtool_ops(struct net_device *netdev)
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 8e610a1..b0731e6 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -77,8 +77,6 @@
>
> #define STMMAC_ALIGN(x) L1_CACHE_ALIGN(x)
> #define JUMBO_LEN 9000
> -#define STMMAC_TX_TM 40000
> -#define STMMAC_TX_MAX_FRAMES 32 /* Max coalesced frame */
>
> /* Module parameters */
> #define TX_TIMEO 5000 /* default 5 seconds */
> @@ -140,6 +138,8 @@ static int stmmac_init_fs(struct net_device *dev);
> static void stmmac_exit_fs(void);
> #endif
>
> +#define STMMAC_COAL_TIMER(x) (jiffies + usecs_to_jiffies(x))
> +
> /**
> * stmmac_verify_args - verify the driver parameters.
> * Description: it verifies if some wrong parameter is passed to the driver.
> @@ -996,9 +996,9 @@ static void stmmac_init_tx_coalesce(struct stmmac_priv *priv)
> {
> /* Set Tx coalesce parameters and timers */
> priv->tx_coal_frames = STMMAC_TX_MAX_FRAMES;
> - priv->tx_coal_timer = jiffies + usecs_to_jiffies(STMMAC_TX_TM);
> + priv->tx_coal_timer = STMMAC_COAL_TX_TIMER;
> init_timer(&priv->txtimer);
> - priv->txtimer.expires = priv->tx_coal_timer;
> + priv->txtimer.expires = STMMAC_COAL_TIMER(priv->tx_coal_timer);
> priv->txtimer.data = (unsigned long)priv;
> priv->txtimer.function = stmmac_txtimer;
> add_timer(&priv->txtimer);
> @@ -1118,11 +1118,10 @@ static int stmmac_open(struct net_device *dev)
>
> stmmac_init_tx_coalesce(priv);
>
> - if ((priv->use_riwt) && (priv->hw->dma->rx_watchdog))
> - /* Program RX Watchdog register to the default values
> - * FIXME: provide user value for RIWT
> - */
> - priv->hw->dma->rx_watchdog(priv->ioaddr, DEFAULT_DMA_RIWT);
> + if ((priv->use_riwt) && (priv->hw->dma->rx_watchdog)) {
> + priv->rx_riwt = MAX_DMA_RIWT;
> + priv->hw->dma->rx_watchdog(priv->ioaddr, MAX_DMA_RIWT);
> + }
>
> napi_enable(&priv->napi);
>
> @@ -1299,7 +1298,8 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
> priv->xstats.tx_reset_ic_bit++;
> TX_DBG("\t[entry %d]: tx_count_frames %d\n", entry,
> priv->tx_count_frames);
> - mod_timer(&priv->txtimer, priv->tx_coal_timer);
> + mod_timer(&priv->txtimer,
> + STMMAC_COAL_TIMER(priv->tx_coal_timer));
> } else
> priv->tx_count_frames = 0;
>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* NIC emulation with built-in rate limiting?
From: Rick Jones @ 2012-09-11 18:07 UTC (permalink / raw)
To: netdev, kvm; +Cc: Lee Schermerhorn, Brian Haley
Are there NIC emulations in the kernel with built-in rate limiting? Or
is that supposed to be strictly the province of qdiscs/filters?
I've been messing about with netperf in a VM using virtio_net, to which
rate limiting has been applied to its corresponding vnetN interface -
rate policing on vnetN ingress (the VM's outbound) and htb on the vnetN
egress (the VM's inbound).
Looking at the "demo mode" output of netperf and a VM throttled to 800
Mbit/s in each direction I see that inbound to the VM is quite steady
over time - right at about 800 Mbit/s. However, looking at that same
sort of data for outbound from the VM shows considerable variability
ranging anywhere from 700 to 900 Mbit/s (though the bulk of the
variability is clustered more like 750 to 850.
I was thinking that part of the reason may stem from the lack of direct
feedback to the VM since the policing is on the vnetN interface and
wondered if it might be "better" if the VM's outbound network rate were
constrained not by an ingress policing filter on the vnetN interface but
by the host/hypervisor/emulator portion of the NIC and how quickly it
pulls packets from the tx queue. That would allow the queue which
built-up to be in the VM itself and would more accurately represent what
a "real NIC" of that bandwidth would do.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: [Open-FCoE] [RFC PATCH 0/5] Reorganize libfcoe control interfaces
From: Love, Robert W @ 2012-09-11 17:46 UTC (permalink / raw)
To: Chris Leech
Cc: netdev@vger.kernel.org, devel@open-fcoe.org,
linux-scsi@vger.kernel.org, gregkh@linuxfoundation.org
In-Reply-To: <504F76A1.50809@intel.com>
On Tue 11 Sep 2012 10:36:35 AM PDT, Love, Robert W wrote:
> On Tue 11 Sep 2012 10:06:29 AM PDT, Chris Leech wrote:
>> On Mon, Sep 10, 2012 at 3:59 PM, Robert Love <robert.w.love@intel.com> wrote:
<snip>
>> That being said, I'm glad this is being reworked. Do you have any
>> other functionality in mind that this is laying the groundwork for?
>>
>
> I have one feature and a few ideas. I currently have a patch that adds
> a fabric selection feature. I add another RW attribute to the ctlr_X
> device. If the user writes fabric name to the file libfcoe uses it in
> it's FCF selection algorithm. Here's my commit message from that patch.
> I can share the patch if people would like to see it too. The current
> implementation also allows the user to force the login through a
> specific FCF.
>
My fcoe-utils.git change here also allows the user to drive this fabric
selection using a new variable in the /etc/fcoe/cfg-ethX files that the
'fcoe service' uses.
^ permalink raw reply
* Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces
From: Love, Robert W @ 2012-09-11 17:43 UTC (permalink / raw)
To: Chris Leech
Cc: netdev@vger.kernel.org, gregkh@linuxfoundation.org,
linux-scsi@vger.kernel.org, devel@open-fcoe.org,
Bhanu Prakash Gollapudi
In-Reply-To: <CAHNqLyXhUo9ny3Wez5kWazaj_bk7mOEqvB8TemkFsu8ZP-ypXw@mail.gmail.com>
On Tue 11 Sep 2012 10:12:09 AM PDT, Chris Leech wrote:
> On Mon, Sep 10, 2012 at 5:05 PM, Bhanu Prakash Gollapudi
> <bprakash@broadcom.com> wrote:
>>
>> I'm concerned that we will be breaking user space compatibility with this
>> change, as there should be a corresponding fcoemon/fipvlan change along with
>> this, and existing utilities will not work. Also the way we start fcoe will
>> be completely different and the user may need to do the scripting changes,
>> if any.
>>
>
> I agree with Bhanu on these concerns, even though I hope everyone's
> using fcoeadm/fcoemon/fipvlan. I think there needs to be more of a
> transition plan than requiring everyone moving to a new kernel to
> update the user-space tools at the same time. Removing the module
> parameters with the last patch might be rushed, they should probably
> remain for a few kernel cycles with a warning. When the tools are
> updated for the new interface, they should probably maintain fallback
> support for the module parameters for a while as well.
>
Deprecating the old interfaces instead of immediately removing them
sounds like a good idea to me.
I hope everyone is using fcoeadm/fcoemon/fipvlan too. We do still carry
the 'fcc.sh' script in fcoe-utils.git/contrib/. I don't use it, but I
know others do. I did not update 'fcc.sh' with my user space change.
I'll post the fcoemon changes to devel@open-fcoe.org. I think I have a
bunch of cleanup patches that the change depends on, so the series will
probably be half cleanup and half feature.
Thanks, //Rob
^ permalink raw reply
* Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces
From: Love, Robert W @ 2012-09-11 17:36 UTC (permalink / raw)
To: Chris Leech
Cc: netdev@vger.kernel.org, gregkh@linuxfoundation.org,
linux-scsi@vger.kernel.org, bprakash@broadcom.com,
devel@open-fcoe.org
In-Reply-To: <CAHNqLyUUeVPVzvZCKzmbp0LdOGnOYudOehVfagySokrq8zj4hA@mail.gmail.com>
On Tue 11 Sep 2012 10:06:29 AM PDT, Chris Leech wrote:
> On Mon, Sep 10, 2012 at 3:59 PM, Robert Love <robert.w.love@intel.com> wrote:
<snip>
>> 1) Create/alloc the port
>> - Allocate kernel memory and create per-instance sysfs devices
>> - No discovery or login
>>
# echo eth3.172-fcoe > /sys/bus/fcoe/ctlr_create
results in:
/sys/bus/fcoe/devices/ctlr_0/
>> 2) Configure the port
>> - Change mode, set ddp_min, etc...
>>
# echo "Fabric" > /sys/bus/fcoe/devices/ctlr_0/mode
no visible change
>> 3) Start the port
>> - Begins discovery and/or login (depending on mode)
>>
# echo 1 > /sys/bus/fcoe/devices/ctlr_0/start
Begins discovery and login. Assuming there are FCFs then results in:
/sys/bus/fcoe/devices/fcf_0
>> 4) Destroy the port
>> - Logout and free all memory
# echo eth3.172-fcoe > /sys/bus/fcoe/ctlr_destroy
/sys/bus/fcoe/devices/ctlr_0 is removed.
>>
>> I'm looking for feedback on using sysfs files as control interfaces that
>> the user (application) would write interface names to. I modeled this
>> series off of the bonding sysfs interface, but it was suggested to me that
>> it might not be a good example. I belive bonding uses two values per-file
>> a '+' or a '-" to add or delete and then the ifname apended. I am simply
>> writing the ifname to the ctlr_create or ctlr_destroy.
>
> Can you give an example session that goes through the 4 steps above
> and what the sysfs hierarchy looks like at each step? I mostly get it
> from the patch descriptions, but I think it would help discussion of
> your proposed interfaces to see an example of them in use.
>
See above. bash-style.
> This feels a little awkward with all the special control files. Have
> you thought about something designed for creating kernel objects, like
> configfs? Similarly the separate start, enable, disable files vs.
Let me do some more reading about configfs. I may not have given it
enough thought.
> having some sort of status attribute that can take different values.
> I feel like these need to be rethought as attributes instead of
> triggers. Is there a big difference between start and enable? Can
> you achieve the split between create and start by having it come up in
> a disabled state by default?
>
It's a good idea. I'll look into it.
> That being said, I'm glad this is being reworked. Do you have any
> other functionality in mind that this is laying the groundwork for?
>
I have one feature and a few ideas. I currently have a patch that adds
a fabric selection feature. I add another RW attribute to the ctlr_X
device. If the user writes fabric name to the file libfcoe uses it in
it's FCF selection algorithm. Here's my commit message from that patch.
I can share the patch if people would like to see it too. The current
implementation also allows the user to force the login through a
specific FCF.
libfcoe, bnx2fc, fcoe: Add 'selection' attribute
This patch adds a 'selection' attribute to the
fcoe_ctlr_device. The user can write either a
'0x' prefixed fabric name or a ':' separated
MAC address to this file. If a fabric name is
provided the fcoe ctlr will only consider FCFs
with the fabric name when choosing a FCF to login
to. If a MAC address is provided the initiator
will only login to a FCF with the given Ethernet
address. Only one selection is valid at a time.
There are corresponding changes to fcoe-utils
to take advantage of this kernel feature and
to make it more accessible for the user.
To accompany this feature I created a new fipfcf application based on
fipvlan that sends out a discovery solicitation and displays
advertising FCFs.
I've also been talking with Mark Rustad about doing an 'auto' mode
where Fabric discovery is attempted first and if it fails then it tries
VN2VN discovery, but so for we've only had hallway conversations about
it and nothing has been flushed out.
Thanks, //Rob
^ permalink raw reply
* Re: [V3 PATCH 5/9] csiostor: Chelsio FCoE offload driver submission (sources part 5).
From: David Miller @ 2012-09-11 17:35 UTC (permalink / raw)
To: naresh; +Cc: JBottomley, linux-scsi, dm, leedom, netdev, chethan
In-Reply-To: <1347374347-3852-6-git-send-email-naresh@chelsio.com>
From: Naresh Kumar Inna <naresh@chelsio.com>
Date: Tue, 11 Sep 2012 20:09:03 +0530
> +#include <linux/moduleparam.h>
This header include is not necessary.
^ permalink raw reply
* Re: [V3 PATCH 9/9] cxgb4vf: Chelsio FCoE offload driver submission (header compatibility fixes).
From: David Miller @ 2012-09-11 17:33 UTC (permalink / raw)
To: naresh; +Cc: JBottomley, linux-scsi, dm, leedom, netdev, chethan
In-Reply-To: <1347374347-3852-10-git-send-email-naresh@chelsio.com>
From: Naresh Kumar Inna <naresh@chelsio.com>
Date: Tue, 11 Sep 2012 20:09:07 +0530
> This patch contains minor fixes to make cxgb4vf driver work with the updates to
> shared firmware/hardware header files.
>
> Signed-off-by: Naresh Kumar Inna <naresh@chelsio.com>
You cannot submit a patch set that isn't bisectable, and in particular
create a situation that mid-way through your patch set things do not
build or operate correctly.
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8192ce: Log message that B_CUT device may not work
From: Anisse Astier @ 2012-09-11 17:23 UTC (permalink / raw)
To: Larry Finger
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Stable, Li Chaoming
In-Reply-To: <1347379873-9390-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On Tue, 11 Sep 2012 11:11:13 -0500, Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote :
> There are a number of problems that occur for the latest version
> of the Realtek RTL8188CE device with the in-kernel driver. These
> include selection of the wrong firmware, and system lockup. A full
> fix is known, but is too invasive for inclusion in stable. This patch
> fixes the problem with loading the wrong firmware, and logs a message
> that the device may not work for kernels 3.6 and older.
>
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> Cc: Stable <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Cc: Anisse Astier <anisse-fwwRqrJYcP2HXe+LvDLADg@public.gmane.org>
> Cc: Li Chaoming <chaoming_li-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
Tested-by: Anisse Astier <anisse-fwwRqrJYcP2HXe+LvDLADg@public.gmane.org>
Behaves as expected: I can see the warning then about 20 seconds later
the machine locks up.
Regards,
Anisse
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces
From: Chris Leech @ 2012-09-11 17:12 UTC (permalink / raw)
To: Bhanu Prakash Gollapudi; +Cc: Robert Love, netdev, gregkh, linux-scsi, devel
In-Reply-To: <504E8040.70403@broadcom.com>
On Mon, Sep 10, 2012 at 5:05 PM, Bhanu Prakash Gollapudi
<bprakash@broadcom.com> wrote:
>
> I'm concerned that we will be breaking user space compatibility with this
> change, as there should be a corresponding fcoemon/fipvlan change along with
> this, and existing utilities will not work. Also the way we start fcoe will
> be completely different and the user may need to do the scripting changes,
> if any.
>
I agree with Bhanu on these concerns, even though I hope everyone's
using fcoeadm/fcoemon/fipvlan. I think there needs to be more of a
transition plan than requiring everyone moving to a new kernel to
update the user-space tools at the same time. Removing the module
parameters with the last patch might be rushed, they should probably
remain for a few kernel cycles with a warning. When the tools are
updated for the new interface, they should probably maintain fallback
support for the module parameters for a while as well.
- Chris
^ 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