* Re: [net 0/4][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-03-28 7:04 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1332917548-13102-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 27 Mar 2012 23:52:24 -0700
> This series of patches contains fixes for e1000, igb, igbvf, ixgb,
> ixgbe and ixgbevf.
>
> The following are changes since commit cc3425cdc04206f3c8b9efb2c693e89aa3cd9ec7:
> Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] tcp: remove useless update for flag parameter in tcp_enter_frto_loss()
From: Li Yu @ 2012-03-28 6:54 UTC (permalink / raw)
To: Neal Cardwell; +Cc: netdev
In-Reply-To: <CADVnQymQaCSKx0aRda6OiP=t2OToxHmvjXjYvTdxsq7oFE3DTg@mail.gmail.com>
于 2012年03月28日 13:29, Neal Cardwell 写道:
> On Wed, Mar 28, 2012 at 12:23 AM, Li Yu<raise.sail@gmail.com> wrote:
>>
>> It seem that we forget remove below two lines after copying code :)
>>
>> This update never impacts others.
>
> The 'flag' variable will be used in later iterations of the
> tcp_for_write_queue() loop. The comment seems to quite sensibly
> indicate that the FLAG_DATA_ACKED bit is being set to avoid entering
> that branch of the if statement in later segments in the loop:
>
> 2168 if ((tp->frto_counter == 1)&& !(flag& FLAG_DATA_ACKED)) {
> 2169 /* For some reason this R-bit might get cleared? */
> 2170 if (TCP_SKB_CB(skb)->sacked& TCPCB_SACKED_RETRANS)
> 2171 tp->retrans_out += tcp_skb_pcount(skb);
> 2172 /* ...enter this if branch just for the
> first segment */
> 2173 flag |= FLAG_DATA_ACKED;
> 2174 } else {
>
> The structure of the logic seems intact from the original commit that
> added this:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=d1a54c6a0a3f9c2c4ef71982d89b8571bd9eaa51
>
Sorry for spent time on this, it it account for F-RTO retransmitted
segment here.
Yu
> neal
>
^ permalink raw reply
* [net 4/4] ixgbe: update version number
From: Jeff Kirsher @ 2012-03-28 6:52 UTC (permalink / raw)
To: davem; +Cc: Don Skidmore, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1332917548-13102-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Don Skidmore <donald.c.skidmore@intel.com>
Update the driver version number to better match version of out of tree
driver that has similar functionality.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 6dbad2b..3e26b1f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -63,8 +63,8 @@ static char ixgbe_default_device_descr[] =
"Intel(R) 10 Gigabit Network Connection";
#endif
#define MAJ 3
-#define MIN 6
-#define BUILD 7
+#define MIN 8
+#define BUILD 21
#define DRV_VERSION __stringify(MAJ) "." __stringify(MIN) "." \
__stringify(BUILD) "-k"
const char ixgbe_driver_version[] = DRV_VERSION;
--
1.7.7.6
^ permalink raw reply related
* [net 2/4] intel: make wired ethernet driver message level consistent (rev2)
From: Jeff Kirsher @ 2012-03-28 6:52 UTC (permalink / raw)
To: davem; +Cc: stephen hemminger, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1332917548-13102-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: stephen hemminger <shemminger@vyatta.com>
Dan Carpenter noticed that ixgbevf initial default was different than
the rest. But the problem is broader than that, only one Intel driver (ixgb)
was doing it almost right.
The convention for default debug level should be consistent among
Intel drivers and follow established convention.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 5 +++--
drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++++++-
drivers/net/ethernet/intel/igb/igb_main.c | 7 ++++++-
drivers/net/ethernet/intel/igbvf/netdev.c | 7 ++++++-
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 6 +++---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 ++++++---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 7 +++++--
7 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index bcba9cf..4348b6f 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -217,7 +217,8 @@ MODULE_DESCRIPTION("Intel(R) PRO/1000 Network Driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_VERSION);
-static int debug = NETIF_MSG_DRV | NETIF_MSG_PROBE;
+#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV|NETIF_MSG_PROBE|NETIF_MSG_LINK)
+static int debug = -1;
module_param(debug, int, 0);
MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
@@ -981,7 +982,7 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
adapter = netdev_priv(netdev);
adapter->netdev = netdev;
adapter->pdev = pdev;
- adapter->msg_enable = (1 << debug) - 1;
+ adapter->msg_enable = netif_msg_init(debug, DEFAULT_MSG_ENABLE);
adapter->bars = bars;
adapter->need_ioport = need_ioport;
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 7152eb1..2c38a65 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -60,6 +60,11 @@
char e1000e_driver_name[] = "e1000e";
const char e1000e_driver_version[] = DRV_VERSION;
+#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV|NETIF_MSG_PROBE|NETIF_MSG_LINK)
+static int debug = -1;
+module_param(debug, int, 0);
+MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
+
static void e1000e_disable_aspm(struct pci_dev *pdev, u16 state);
static const struct e1000_info *e1000_info_tbl[] = {
@@ -6172,7 +6177,7 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
adapter->hw.adapter = adapter;
adapter->hw.mac.type = ei->mac;
adapter->max_hw_frame_size = ei->max_hw_frame_size;
- adapter->msg_enable = (1 << NETIF_MSG_DRV | NETIF_MSG_PROBE) - 1;
+ adapter->msg_enable = netif_msg_init(debug, DEFAULT_MSG_ENABLE);
mmio_start = pci_resource_start(pdev, 0);
mmio_len = pci_resource_len(pdev, 0);
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index c490241..5ec3159 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -238,6 +238,11 @@ MODULE_DESCRIPTION("Intel(R) Gigabit Ethernet Network Driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_VERSION);
+#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV|NETIF_MSG_PROBE|NETIF_MSG_LINK)
+static int debug = -1;
+module_param(debug, int, 0);
+MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
+
struct igb_reg_info {
u32 ofs;
char *name;
@@ -1893,7 +1898,7 @@ static int __devinit igb_probe(struct pci_dev *pdev,
adapter->pdev = pdev;
hw = &adapter->hw;
hw->back = adapter;
- adapter->msg_enable = NETIF_MSG_DRV | NETIF_MSG_PROBE;
+ adapter->msg_enable = netif_msg_init(debug, DEFAULT_MSG_ENABLE);
mmio_start = pci_resource_start(pdev, 0);
mmio_len = pci_resource_len(pdev, 0);
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index 217c143..d61ca2a 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -55,6 +55,11 @@ static const char igbvf_driver_string[] =
static const char igbvf_copyright[] =
"Copyright (c) 2009 - 2012 Intel Corporation.";
+#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV|NETIF_MSG_PROBE|NETIF_MSG_LINK)
+static int debug = -1;
+module_param(debug, int, 0);
+MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
+
static int igbvf_poll(struct napi_struct *napi, int budget);
static void igbvf_reset(struct igbvf_adapter *);
static void igbvf_set_interrupt_capability(struct igbvf_adapter *);
@@ -2649,7 +2654,7 @@ static int __devinit igbvf_probe(struct pci_dev *pdev,
adapter->flags = ei->flags;
adapter->hw.back = adapter;
adapter->hw.mac.type = ei->mac;
- adapter->msg_enable = (1 << NETIF_MSG_DRV | NETIF_MSG_PROBE) - 1;
+ adapter->msg_enable = netif_msg_init(debug, DEFAULT_MSG_ENABLE);
/* PCI config space info */
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index 82aaa79..5fce363 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -134,8 +134,8 @@ MODULE_DESCRIPTION("Intel(R) PRO/10GbE Network Driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_VERSION);
-#define DEFAULT_DEBUG_LEVEL_SHIFT 3
-static int debug = DEFAULT_DEBUG_LEVEL_SHIFT;
+#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV|NETIF_MSG_PROBE|NETIF_MSG_LINK)
+static int debug = -1;
module_param(debug, int, 0);
MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
@@ -442,7 +442,7 @@ ixgb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
adapter->netdev = netdev;
adapter->pdev = pdev;
adapter->hw.back = adapter;
- adapter->msg_enable = netif_msg_init(debug, DEFAULT_DEBUG_LEVEL_SHIFT);
+ adapter->msg_enable = netif_msg_init(debug, DEFAULT_MSG_ENABLE);
adapter->hw.hw_addr = pci_ioremap_bar(pdev, BAR_0);
if (!adapter->hw.hw_addr) {
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 398fc22..6dbad2b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -141,13 +141,16 @@ module_param(allow_unsupported_sfp, uint, 0);
MODULE_PARM_DESC(allow_unsupported_sfp,
"Allow unsupported and untested SFP+ modules on 82599-based adapters");
+#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV|NETIF_MSG_PROBE|NETIF_MSG_LINK)
+static int debug = -1;
+module_param(debug, int, 0);
+MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
+
MODULE_AUTHOR("Intel Corporation, <linux.nics@intel.com>");
MODULE_DESCRIPTION("Intel(R) 10 Gigabit PCI Express Network Driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_VERSION);
-#define DEFAULT_DEBUG_LEVEL_SHIFT 3
-
static void ixgbe_service_event_schedule(struct ixgbe_adapter *adapter)
{
if (!test_bit(__IXGBE_DOWN, &adapter->state) &&
@@ -6834,7 +6837,7 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
adapter->pdev = pdev;
hw = &adapter->hw;
hw->back = adapter;
- adapter->msg_enable = (1 << DEFAULT_DEBUG_LEVEL_SHIFT) - 1;
+ adapter->msg_enable = netif_msg_init(debug, DEFAULT_MSG_ENABLE);
hw->hw_addr = ioremap(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 581c659..307611a 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -91,7 +91,10 @@ MODULE_DESCRIPTION("Intel(R) 82599 Virtual Function Driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_VERSION);
-#define DEFAULT_DEBUG_LEVEL_SHIFT 3
+#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV|NETIF_MSG_PROBE|NETIF_MSG_LINK)
+static int debug = -1;
+module_param(debug, int, 0);
+MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
/* forward decls */
static void ixgbevf_set_itr_msix(struct ixgbevf_q_vector *q_vector);
@@ -3367,7 +3370,7 @@ static int __devinit ixgbevf_probe(struct pci_dev *pdev,
adapter->pdev = pdev;
hw = &adapter->hw;
hw->back = adapter;
- adapter->msg_enable = (1 << DEFAULT_DEBUG_LEVEL_SHIFT) - 1;
+ adapter->msg_enable = netif_msg_init(debug, DEFAULT_MSG_ENABLE);
/*
* call save state here in standalone driver because it relies on
--
1.7.7.6
^ permalink raw reply related
* [net 3/4] ixgbe: fix typo in enumeration name
From: Jeff Kirsher @ 2012-03-28 6:52 UTC (permalink / raw)
To: davem; +Cc: Don Skidmore, netdev, gospo, sassmann, Xiaojun Zhang,
Jeff Kirsher
In-Reply-To: <1332917548-13102-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Don Skidmore <donald.c.skidmore@intel.com>
This was pointed out to me by Xiaojun Zhang on Source Forge.
CC: Xiaojun Zhang <zhangxiaojun@sourceforge.net>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 80e26ff..74e1921 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -544,7 +544,7 @@ struct ixgbe_fdir_filter {
u16 action;
};
-enum ixbge_state_t {
+enum ixgbe_state_t {
__IXGBE_TESTING,
__IXGBE_RESETTING,
__IXGBE_DOWN,
--
1.7.7.6
^ permalink raw reply related
* [net 1/4] e1000: fix vlan processing regression
From: Jeff Kirsher @ 2012-03-28 6:52 UTC (permalink / raw)
To: davem; +Cc: Jiri Pirko, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1332917548-13102-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jiri Pirko <jpirko@redhat.com>
This patch fixes a regression introduced by commit "e1000: do vlan
cleanup (799d531)".
Apparently some e1000 chips (not mine) are sensitive about the order of
setting vlan filter and vlan stripping/inserting functionality. So this
patch changes the order so it's the same as before vlan cleanup.
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 35 +++++++++++++++---------
1 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 0e9aec8..bcba9cf 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -164,6 +164,8 @@ static int e1000_82547_fifo_workaround(struct e1000_adapter *adapter,
static bool e1000_vlan_used(struct e1000_adapter *adapter);
static void e1000_vlan_mode(struct net_device *netdev,
netdev_features_t features);
+static void e1000_vlan_filter_on_off(struct e1000_adapter *adapter,
+ bool filter_on);
static int e1000_vlan_rx_add_vid(struct net_device *netdev, u16 vid);
static int e1000_vlan_rx_kill_vid(struct net_device *netdev, u16 vid);
static void e1000_restore_vlan(struct e1000_adapter *adapter);
@@ -1214,7 +1216,7 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
if (err)
goto err_register;
- e1000_vlan_mode(netdev, netdev->features);
+ e1000_vlan_filter_on_off(adapter, false);
/* print bus type/speed/width info */
e_info(probe, "(PCI%s:%dMHz:%d-bit) %pM\n",
@@ -4770,6 +4772,22 @@ static bool e1000_vlan_used(struct e1000_adapter *adapter)
return false;
}
+static void __e1000_vlan_mode(struct e1000_adapter *adapter,
+ netdev_features_t features)
+{
+ struct e1000_hw *hw = &adapter->hw;
+ u32 ctrl;
+
+ ctrl = er32(CTRL);
+ if (features & NETIF_F_HW_VLAN_RX) {
+ /* enable VLAN tag insert/strip */
+ ctrl |= E1000_CTRL_VME;
+ } else {
+ /* disable VLAN tag insert/strip */
+ ctrl &= ~E1000_CTRL_VME;
+ }
+ ew32(CTRL, ctrl);
+}
static void e1000_vlan_filter_on_off(struct e1000_adapter *adapter,
bool filter_on)
{
@@ -4779,6 +4797,7 @@ static void e1000_vlan_filter_on_off(struct e1000_adapter *adapter,
if (!test_bit(__E1000_DOWN, &adapter->flags))
e1000_irq_disable(adapter);
+ __e1000_vlan_mode(adapter, adapter->netdev->features);
if (filter_on) {
/* enable VLAN receive filtering */
rctl = er32(RCTL);
@@ -4799,24 +4818,14 @@ static void e1000_vlan_filter_on_off(struct e1000_adapter *adapter,
}
static void e1000_vlan_mode(struct net_device *netdev,
- netdev_features_t features)
+ netdev_features_t features)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
- struct e1000_hw *hw = &adapter->hw;
- u32 ctrl;
if (!test_bit(__E1000_DOWN, &adapter->flags))
e1000_irq_disable(adapter);
- ctrl = er32(CTRL);
- if (features & NETIF_F_HW_VLAN_RX) {
- /* enable VLAN tag insert/strip */
- ctrl |= E1000_CTRL_VME;
- } else {
- /* disable VLAN tag insert/strip */
- ctrl &= ~E1000_CTRL_VME;
- }
- ew32(CTRL, ctrl);
+ __e1000_vlan_mode(adapter, features);
if (!test_bit(__E1000_DOWN, &adapter->flags))
e1000_irq_enable(adapter);
--
1.7.7.6
^ permalink raw reply related
* [net 0/4][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2012-03-28 6:52 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
This series of patches contains fixes for e1000, igb, igbvf, ixgb,
ixgbe and ixgbevf.
The following are changes since commit cc3425cdc04206f3c8b9efb2c693e89aa3cd9ec7:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master
Don Skidmore (2):
ixgbe: fix typo in enumeration name
ixgbe: update version number
Jiri Pirko (1):
e1000: fix vlan processing regression
stephen hemminger (1):
intel: make wired ethernet driver message level consistent (rev2)
drivers/net/ethernet/intel/e1000/e1000_main.c | 40 +++++++++++++--------
drivers/net/ethernet/intel/e1000e/netdev.c | 7 +++-
drivers/net/ethernet/intel/igb/igb_main.c | 7 +++-
drivers/net/ethernet/intel/igbvf/netdev.c | 7 +++-
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 6 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 13 ++++---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 7 +++-
8 files changed, 60 insertions(+), 29 deletions(-)
--
1.7.7.6
^ permalink raw reply
* Re: a F-RTO question
From: Li Yu @ 2012-03-28 6:43 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Chao Pei, netdev
In-Reply-To: <CAK6E8=cgHxQMXA9QVu6=v6OqRAd6v7-wsEpM9ENFhqDpn88GvQ@mail.gmail.com>
于 2012年03月28日 13:35, Yuchung Cheng 写道:
> On Tue, Mar 27, 2012 at 9:08 PM, Li Yu<raise.sail@gmail.com> wrote:
>> 于 2012年03月28日 11:49, Chao Pei 写道:
>>
>>>> Hi,
>>>>
>>>> I have a question about tcp_process_frto(), the below source
>>>> code :
>>>>
>>>> static int tcp_process_frto(struct sock *sk, int flag)
>>>> {
>>>> .....
>>>>
>>>> if (!before(tp->snd_una, tp->frto_highmark)) {
>>>> tcp_enter_frto_loss(sk, ...);
>>>> return 1;
>>>> }
>>>>
>>>> .....
>>>>
>>>> }
>>>>
>>>> As my understanding, the tp->frto_highmark likes tp->high_seq,
>>>> it saves the seqno SND_NXT when a TCP connection enters F-RTO phase,
>>>> is it the variable "recovery" in NewReno? So I think that if snd_una is
>>>> equal with or after frto_highmark, which means peer ack new data, so
>>>> why we enter Loss state here?
>>>>
>>>> Thanks!
>>>>
>>>> Yu
>>>>
>>>>
>>>
>>> If snd_una advances to frto_highmark, it is likely that the hole was
>>> filled by the retransimitted packet, which means the original packet
>>> was likely to have been lost.
>>> So, we should enter loss state.
>>>
>>
>> I do not agree with it, if snd_una advanced to frto_highmark, which means
>> peer acks whole window of data instead of just one segment, and
>> we can not make sure that reason of peer sends ack is whether it received
>> original segment or retransmitted segment.
>>
>> Even, the reason is latter, it also means the netowrk already is
>> recovered from temporarily congestion or disordered state, so we also should
>> not enter loss state.
> Like you said there is some ambiguity and F-RTO takes the conservative approach.
> You can find answers to your question in RFC 5682 (Section 2.2). Unless the RTO
> is proven to be spurious, TCP should reduce window and performs
> slow-start regardlessly.
>
I think I got it, if the new ack covers "frto_highmark",
it may mean the fast retransmitted segments are lost likely.
In RFC5682:
If the first acknowledgment after the RTO retransmission covers the
"recover" point at algorithm step (2a), there is not enough evidence
that a non-retransmitted segment has arrived at the receiver after
the timeout. This is a common case when a fast retransmission is
lost and has been retransmitted again after an RTO, while the rest of
the unacknowledged segments were successfully delivered to the TCP
receiver before the retransmission timeout. Therefore, the timeout
cannot be declared spurious in this case.
And as Chao's words, if the RTO is proven, we should enter
slow-start then.
Thanks!
Yu
^ permalink raw reply
* compat-wireless releases based on v3.3
From: Luis R. Rodriguez @ 2012-03-28 6:41 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless, linux-bluetooth, netdev-u79uwXL29TY76Z2rM5mHXA,
lf_driver_backport-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
Linux v3.3 is out, so we make kernel backport releases based on this
release to allow you to compile subsystems / drivers from this kernel
on older kernels. One kernel backport release is based on v3.3 vanilla
[0], and another which cherry picks 14 patches from linux-next.git
[1]. The linux-next-cherry-picks patches are just one of the type of
extra categories of patches which the projects allows, for more
details refer to the additional patches page [2]. For details on the
changes that went into the kernel for the subsystem / drivers we
include in this release please refer to the ChangeLog [3]. Details to
compat and compat-wireless are provided below.
Worth mentioning is we now have a documentation page for the compat
module alone [4]. I've also dumped into a Google Fusion Table kernel
backport statistics [5] which we can use to keep metrics across
different releases. If anyone is interested in helping with these
stats or creating visualizations please let me know, for now anyone
can view the content. I'm still working on the columns, it seems there
a few bugs still with Fusion Table but the prospects of using it are
very nice. In particular I hope it can help organizations keep track
of deltas not upstream, help categorize clearly and keep metrics of
what is not even posted but needed (we call this crap), etc. There are
also slides available now [6] that will be used to for the Linux
Collaboration Summit talk on Automatically backporting the Linux
kernel [7]. Hope the new set of documentation helps understand this
process a little better.
The 14 cherry picked patches:
mcgrof@tux ~/devel/compat-wireless (git::linux-3.3.y)$ ls -1
linux-next-cherry-picks/
0001-mac80211-Fix-incorrect-num_sta_ps-decrement-in-__sta.patch
0002-mac80211-Fix-incorrect-num_sta_ps-decrement-in-ap_st.patch
0003-mac80211-Move-num_sta_ps-counter-decrement-after-syn.patch
0004-ath9k-Initialize-NF-values-properly.patch
0005-ath9k-Fix-programming-SYNTH4-for-AR9462.patch
0006-ath9k-Fix-descriptor-length-for-AR9462.patch
0007-mac80211-handle-non-bufferable-MMPDUs-correctly.patch
0008-Revert-ath9k_hw-Fix-false-tx-hung-detection-in-AR900.patch
0009-ath9k-do-not-call-ath9k_hw_txprocdesc-on-AR9003-outs.patch
0010-ath9k_hw-enable-interrupts-for-beacon-tx-completion-.patch
0011-ath9k-fix-drv_tx_last_beacon-on-AR9003-by-processing.patch
0012-ath9k_hw-use-cold-instead-of-warm-reset-on-AR9280.patch
0013-mac80211-add-an-rx-flag-for-ignoring-a-packet-s-sign.patch
0014-ath9k-fix-signal-strength-reporting-issues.patch
===============================================
ChangeLog for compat-wireless for linux-3.3
===============================================
This is the ChangeLog for the Linux kernel project compat-wireless.
It provides a backport of a few Linux kernel subsystems down to
older kernels:
* 802.11
* Bluetooth
* Ethernet
For more details refer to the home page:
http://wireless.kernel.org/en/users/Download/stable/
The compat-wireless project consists of code from three projects:
* The Linux kernel: linux-2.6-allstable.git
* Compat-wirelesS: compat-wireless.git
* Compat: compat.git
The compat-wireless stable releases incorporates code from from
each of these git trees for the respective upstream Linux kernel
stable release. A branch called linux-3.x.y exists for each
stable release. Below we provide the ChangeLog of changes from
the previous branched release to the new branched release.
Release: linux-3.3
Updates from the compat.git project:
====================================
git shortlog linux-3.2.y..linux-3.3.y
Felix Fietkau (3):
compat: fix misplaced #ifdef for the workqueue backport
compat: backport atomic64 support
compat: fix security_sk_clone dummy backport compile
Hauke Mehrtens (6):
compat: add support for kernel 3.2
compat: backport kfree_rcu()
compat: backport netdev_features_t
compat: add config var for CORDIC and CRC8
compat: add module_usb_driver and module_platform_driver
compat: add __cancel_delayed_work()
John W. Linville (7):
compat: use separate CONFIG_COMPAT_KFIFO option for building kfifo.o
compat: add CONFIG_COMPAT_FIRMWARE_DATA_RW_NEEDS_FILP
compat: check CONFIG_COMPAT_FIRMWARE_CLASS in compat-2.6.33.h
compat: support RHEL6 as a build target
compat: avoid warning in compat_system_workqueue_create
compat: implement dummy security_sk_clone
compat: use kconfig.h in compat-2.6.h for 3.1 and later kernels
Luis R. Rodriguez (4):
compat: fix building for 3.0 kernels
compat: export compat kernel versions info
compat: add .gitignore
compat: add compat kernel checker and downloader
Nikolay Martynov (1):
Add dma_zalloc_coherent to fix build with kernels older than 3.2
Updates from the compat-wireless.git project:
=============================================
git shortlog linux-3.2.y..linux-3.3.y
Dominique Martinet (1):
compat-wireless: build: Throw error if space in path
Eliad Peller (1):
compat-wireless: fix patches/08-rename-config-options.patch
Hauke Mehrtens (17):
compat-wireless: add support for kernel 3.2
compat-wireless: remove kfree_rcu() patch
compat-wireless: make patches apply again
compat-wireless: make patches apply again
compat-wireless: escape &
compat-wireless: add config var for CORDIC and CRC8
compat-wireless: remove some modules from Makefile
compat-wireless: fix driver-select for intel
compat-wireless: add some missing config options
compat-wireless: fix brcm80211 driver-select
compat-wireless deactivate mac80211 tracing for old kernels
compat-wireless: compile fix for commit patches/09-threaded-irq.patch
compat-wireless: remove platform_device_id for kernel < 2.6.30
compat-wireless: CONFIG_BT_L2CAP and CONFIG_BT_SCO removed
compat-wireless: make patches apply again
compat-wireless: use other workqueue
compat-wireless: no trans_start on netdev_queue
Johannes Berg (1):
compat-wireless: disable SKB TX status stamping in mac80211
John W. Linville (9):
compat-wireless: add CONFIG_COMPAT_KFIFO setting to config.mk
compat-wireless: remove leading whitespace from
CONFIG_COMPAT_FIRMWARE_CLASS
compat-wireless: add CONFIG_COMPAT_BT_SOCK_CREATE_NEEDS_KERN
compat-wireless: support RHEL6 as a build target
compat-wireless: change CONFIG_IWLAGN -> CONFIG_IWLWIFI
compat-wireless: fix patches/11-dev-pm-ops.patch
compat-wireless: fix patches/38-led-max-brightness.patch
compat-wireless: fix patches/39-remove_blink_set.patch
Enable CONFIG_RT2800{PCI,USB}_RT53XX
Luciano Coelho (1):
compat-wireless: check if modprobe exists before using it
Luis R. Rodriguez (22):
compat-wireless: fix patches/08-rename-config-options.patch
compat-wireless: refresh patches
compat-wireless: refresh patches
compat-wireless: fix patches/09-threaded-irq.patch
compat-wireless: refresh patches
compat-wireless: copy driver files only if present
compat-wireless: clarify patches/47-no_trans_start_on_netdev_queue.patch
compat-wireless: clarify patches/46-use_other_workqueue.patch
compat-wireless: refresh patches
compat-wireless: refresh patches for next-20120109
compat-wirless: refresh patches
compat-wireless: refresh patches for 3.3-rc1
compat-wireless: use linux-stable instead of linux-2.6-allstable
compat-wireless: fix patches/16-bluetooth.patch
compat-wireless: refresh patches
compat-wireless: add driver-select option ath9k_ap
compat-wireless: fix allowing jobserver
compat-wireless: add linux-next-cherry-picks for 3.3 recommended by nbd
compat-wireless: refresh linux-next-cherry-picks patches
compat-wireless: remove ath9k packet log crap
compat-wireless: remove stale pending-stable ignore patch
compat-wireless: refresh patches for v3.0 release
[0] http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.3/compat-wireless-3.3-1.tar.bz2
[1] http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.3/compat-wireless-3.3-1-n.tar.bz2
[2] http://wireless.kernel.org/en/users/Download/stable/#Additional_patches_to_stable_releases
[3] http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.3/ChangeLog-3.3-wireless
[4] http://mcgrof.github.com/compat/
[5] https://www.google.com/fusiontables/DataSource?docid=1wXnm0VFUHBpaMmxwjaZZD58B4o8K1iPFCCOx50Q
[6] https://docs.google.com/presentation/d/1axVNEGwKZjnzG1ocdd289WMqPxzJ3qfMv70ghGcnUKc/edit
[7] https://events.linuxfoundation.org/events/collaboration-summit/rodriguez-backporting
Luis
^ permalink raw reply
* Re: [PATCH v4] Ethernet driver for the WIZnet W5300 chip
From: David Miller @ 2012-03-28 6:22 UTC (permalink / raw)
To: msink; +Cc: netdev
In-Reply-To: <4F72A72B.5020609@permonline.ru>
From: Mike Sinkovsky <msink@permonline.ru>
Date: Wed, 28 Mar 2012 11:52:43 +0600
> 28.03.2012 8:35, David Miller wrote:
>
> From Documentation/netdev-features.txt:
>
>>NETIF_F_VLAN_CHALLENGED should be set for devices which can't cope
>>with VLAN
>>headers. Some drivers set this because the cards can't handle the
>>bigger MTU.
>>[FIXME: Those cases could be fixed in VLAN code by allowing only
>>reduced-MTU
>>VLANs. This may be not useful, though.]
>
> My case is exactly what is here in FIXME comment - yes, this chip
> cannot handle full size MTU for VLANs, and TCP/IP traffic don't work
> well over this VLAN.
I disagree with the comment in that document, I didn't write it.
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: do not rate limit counter increments
From: Rusty Russell @ 2012-03-28 6:03 UTC (permalink / raw)
To: Rick Jones, netdev; +Cc: virtualization, mst
In-Reply-To: <20120327172809.C52572900384@tardy>
On Tue, 27 Mar 2012 10:28:09 -0700 (PDT), raj@tardy.cup.hp.com (Rick Jones) wrote:
> From: Rick Jones <rick.jones2@hp.com>
>
> While it is desirable to rate limit certain messages, it is not
> desirable to rate limit the incrementing of counters associated
> with those messages.
>
> Signed-off-by: Rick Jones <rick.jones2@hp.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Thanks!
Rusty.
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 019da01..4de2760 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -625,12 +625,13 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
>
> /* This can happen with OOM and indirect buffers. */
> if (unlikely(capacity < 0)) {
> - if (net_ratelimit()) {
> - if (likely(capacity == -ENOMEM)) {
> + if (likely(capacity == -ENOMEM)) {
> + if (net_ratelimit()) {
> dev_warn(&dev->dev,
> "TX queue failure: out of memory\n");
> } else {
> - dev->stats.tx_fifo_errors++;
> + dev->stats.tx_fifo_errors++;
> + if (net_ratelimit())
> dev_warn(&dev->dev,
> "Unexpected TX queue failure: %d\n",
> capacity);
>
--
How could I marry someone with more hair than me? http://baldalex.org
^ permalink raw reply
* Re: [PATCH v4] Ethernet driver for the WIZnet W5300 chip
From: Mike Sinkovsky @ 2012-03-28 5:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120327.223545.1996930432677091672.davem@davemloft.net>
28.03.2012 8:35, David Miller wrote:
>> +/*
>> + * Frame size is hardwired to 1514 bytes (including header),
>> + * => MTU for 802.1Q frames must be set to 1500-4 = 1496
>> + */
>> +#define W5300_HARD_MTU 1500
>
> I've told you that you must set the VLAN challenged feature flag
> (NETIF_F_VLAN_CHALLENGED) for devices which have this restriction.
>
> Just set that, and remove this comment, since the feature bit setting
> documents this restriction fully and perfectly.
From Documentation/netdev-features.txt:
>NETIF_F_VLAN_CHALLENGED should be set for devices which can't cope
with VLAN
>headers. Some drivers set this because the cards can't handle the
bigger MTU.
>[FIXME: Those cases could be fixed in VLAN code by allowing only
reduced-MTU
>VLANs. This may be not useful, though.]
My case is exactly what is here in FIXME comment - yes, this chip cannot
handle full size MTU for VLANs, and TCP/IP traffic don't work well over
this VLAN. But we actually use it for traffic where frame size is known
to be less than 1500 - TDMoE to Asterisk in our case - and it works
perfectly.
So as ideal we'll like to disable TCP/IP over this sort of VLANs, but
still enable TDMoE traffic. If it is possible.
But if you want - ok, I'll disable VLAN support entirely for this chip
in mainline version.
(Now working on similar driver for W5100 chip, hopefully will post both
soon.)
--
Mike
^ permalink raw reply
* [V6 PATCH] virtio-net: send gratuitous packets when needed
From: Jason Wang @ 2012-03-28 5:44 UTC (permalink / raw)
To: netdev, rusty, mst, linux-kernel, virtualization; +Cc: davem, qemu-devel
As hypervior does not have the knowledge of guest network configuration, it's
better to ask guest to send gratuitous packets when needed.
Guest tests VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it
is set, a workqueue is scheduled to send gratuitous packet through
NETDEV_NOTIFY_PEERS. This feature is negotiated through bit
VIRTIO_NET_F_GUEST_ANNOUNCE.
Changes from v5:
- notify the chain before acking the link annoucement
- ack the link announcement notification through control vq
Changes from v4:
- typos
- handle workqueue unconditionally
- move VIRTIO_NET_S_ANNOUNCE to bit 8 to separate rw bits from ro bits
Changes from v3:
- cancel the workqueue during freeze
Changes from v2:
- fix the race between unregister_dev() and workqueue
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/virtio_net.c | 32 +++++++++++++++++++++++++++++++-
include/linux/virtio_net.h | 13 +++++++++++++
2 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4880aa8..0f60da7 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -72,6 +72,9 @@ struct virtnet_info {
/* Work struct for refilling if we run low on memory. */
struct delayed_work refill;
+ /* Work struct for sending gratuitous packets. */
+ struct work_struct announce;
+
/* Chain pages by the private ptr. */
struct page *pages;
@@ -781,12 +784,30 @@ static bool virtnet_send_command(struct virtnet_info *vi, u8 class, u8 cmd,
return status == VIRTIO_NET_OK;
}
+static void virtnet_ack_link_announce(struct virtnet_info *vi)
+{
+ if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_ANNOUNCE,
+ VIRTIO_NET_CTRL_ANNOUNCE_ACK, NULL,
+ 0, 0)) {
+ dev_warn(&vi->dev->dev, "Failed to ack link nnounce.\n");
+ }
+}
+
+static void announce_work(struct work_struct *work)
+{
+ struct virtnet_info *vi = container_of(work, struct virtnet_info,
+ announce);
+ netif_notify_peers(vi->dev);
+ virtnet_ack_link_announce(vi);
+}
+
static int virtnet_close(struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
/* Make sure refill_work doesn't re-enable napi! */
cancel_delayed_work_sync(&vi->refill);
+ cancel_work_sync(&vi->announce);
napi_disable(&vi->napi);
return 0;
@@ -962,11 +983,17 @@ static void virtnet_update_status(struct virtnet_info *vi)
return;
/* Ignore unknown (future) status bits */
- v &= VIRTIO_NET_S_LINK_UP;
+ v &= VIRTIO_NET_S_LINK_UP | VIRTIO_NET_S_ANNOUNCE;
if (vi->status == v)
return;
+ if (v & VIRTIO_NET_S_ANNOUNCE) {
+ v &= ~VIRTIO_NET_S_ANNOUNCE;
+ if (v & VIRTIO_NET_S_LINK_UP)
+ schedule_work(&vi->announce);
+ }
+
vi->status = v;
if (vi->status & VIRTIO_NET_S_LINK_UP) {
@@ -1076,6 +1103,7 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free;
INIT_DELAYED_WORK(&vi->refill, refill_work);
+ INIT_WORK(&vi->announce, announce_work);
sg_init_table(vi->rx_sg, ARRAY_SIZE(vi->rx_sg));
sg_init_table(vi->tx_sg, ARRAY_SIZE(vi->tx_sg));
@@ -1187,6 +1215,7 @@ static int virtnet_freeze(struct virtio_device *vdev)
virtqueue_disable_cb(vi->svq);
if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ))
virtqueue_disable_cb(vi->cvq);
+ cancel_work_sync(&vi->announce);
netif_device_detach(vi->dev);
cancel_delayed_work_sync(&vi->refill);
@@ -1233,6 +1262,7 @@ static unsigned int features[] = {
VIRTIO_NET_F_GUEST_ECN, VIRTIO_NET_F_GUEST_UFO,
VIRTIO_NET_F_MRG_RXBUF, VIRTIO_NET_F_STATUS, VIRTIO_NET_F_CTRL_VQ,
VIRTIO_NET_F_CTRL_RX, VIRTIO_NET_F_CTRL_VLAN,
+ VIRTIO_NET_F_GUEST_ANNOUNCE,
};
static struct virtio_driver virtio_net_driver = {
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 970d5a2..383e8a0 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -49,8 +49,10 @@
#define VIRTIO_NET_F_CTRL_RX 18 /* Control channel RX mode support */
#define VIRTIO_NET_F_CTRL_VLAN 19 /* Control channel VLAN filtering */
#define VIRTIO_NET_F_CTRL_RX_EXTRA 20 /* Extra RX mode control support */
+#define VIRTIO_NET_F_GUEST_ANNOUNCE 21 /* Guest can send gratituous packet */
#define VIRTIO_NET_S_LINK_UP 1 /* Link is up */
+#define VIRTIO_NET_S_ANNOUNCE 2 /* Announcement is needed */
struct virtio_net_config {
/* The config defining mac address (if VIRTIO_NET_F_MAC) */
@@ -152,4 +154,15 @@ struct virtio_net_ctrl_mac {
#define VIRTIO_NET_CTRL_VLAN_ADD 0
#define VIRTIO_NET_CTRL_VLAN_DEL 1
+/*
+ * Control link announce acknowledgement
+ *
+ * The command VIRTIO_NET_CTRL_ANNOUNCE_ACK is used to indicate that
+ * driver has recevied the notification and device would clear the
+ * VIRTIO_NET_S_ANNOUNCE bit in the status filed after it received
+ * this command.
+ */
+#define VIRTIO_NET_CTRL_ANNOUNCE 3
+ #define VIRTIO_NET_CTRL_ANNOUNCE_ACK 0
+
#endif /* _LINUX_VIRTIO_NET_H */
^ permalink raw reply related
* Re: a F-RTO question
From: Yuchung Cheng @ 2012-03-28 5:35 UTC (permalink / raw)
To: Li Yu; +Cc: Chao Pei, netdev
In-Reply-To: <4F728EC9.1050302@gmail.com>
On Tue, Mar 27, 2012 at 9:08 PM, Li Yu <raise.sail@gmail.com> wrote:
> 于 2012年03月28日 11:49, Chao Pei 写道:
>
>>> Hi,
>>>
>>> I have a question about tcp_process_frto(), the below source
>>> code :
>>>
>>> static int tcp_process_frto(struct sock *sk, int flag)
>>> {
>>> .....
>>>
>>> if (!before(tp->snd_una, tp->frto_highmark)) {
>>> tcp_enter_frto_loss(sk, ...);
>>> return 1;
>>> }
>>>
>>> .....
>>>
>>> }
>>>
>>> As my understanding, the tp->frto_highmark likes tp->high_seq,
>>> it saves the seqno SND_NXT when a TCP connection enters F-RTO phase,
>>> is it the variable "recovery" in NewReno? So I think that if snd_una is
>>> equal with or after frto_highmark, which means peer ack new data, so
>>> why we enter Loss state here?
>>>
>>> Thanks!
>>>
>>> Yu
>>>
>>>
>>
>> If snd_una advances to frto_highmark, it is likely that the hole was
>> filled by the retransimitted packet, which means the original packet
>> was likely to have been lost.
>> So, we should enter loss state.
>>
>
> I do not agree with it, if snd_una advanced to frto_highmark, which means
> peer acks whole window of data instead of just one segment, and
> we can not make sure that reason of peer sends ack is whether it received
> original segment or retransmitted segment.
>
> Even, the reason is latter, it also means the netowrk already is
> recovered from temporarily congestion or disordered state, so we also should
> not enter loss state.
Like you said there is some ambiguity and F-RTO takes the conservative approach.
You can find answers to your question in RFC 5682 (Section 2.2). Unless the RTO
is proven to be spurious, TCP should reduce window and performs
slow-start regardlessly.
^ permalink raw reply
* Re: [PATCH] tcp: remove useless update for flag parameter in tcp_enter_frto_loss()
From: Neal Cardwell @ 2012-03-28 5:29 UTC (permalink / raw)
To: Li Yu; +Cc: netdev
In-Reply-To: <4F729235.8040706@gmail.com>
On Wed, Mar 28, 2012 at 12:23 AM, Li Yu <raise.sail@gmail.com> wrote:
>
> It seem that we forget remove below two lines after copying code :)
>
> This update never impacts others.
The 'flag' variable will be used in later iterations of the
tcp_for_write_queue() loop. The comment seems to quite sensibly
indicate that the FLAG_DATA_ACKED bit is being set to avoid entering
that branch of the if statement in later segments in the loop:
2168 if ((tp->frto_counter == 1) && !(flag & FLAG_DATA_ACKED)) {
2169 /* For some reason this R-bit might get cleared? */
2170 if (TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_RETRANS)
2171 tp->retrans_out += tcp_skb_pcount(skb);
2172 /* ...enter this if branch just for the
first segment */
2173 flag |= FLAG_DATA_ACKED;
2174 } else {
The structure of the logic seems intact from the original commit that
added this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=d1a54c6a0a3f9c2c4ef71982d89b8571bd9eaa51
neal
^ permalink raw reply
* Re: [PATCH] tcp: remove useless update for flag parameter in tcp_enter_frto_loss()
From: Yuchung Cheng @ 2012-03-28 5:27 UTC (permalink / raw)
To: Li Yu; +Cc: netdev
In-Reply-To: <4F729235.8040706@gmail.com>
On Tue, Mar 27, 2012 at 9:23 PM, Li Yu <raise.sail@gmail.com> wrote:
>
> It seem that we forget remove below two lines after copying code :)
>
> This update never impacts others.
>
> Sorry for last mail with legal notices improperly, I used wrong
> mail.
>
> Signed-off-by Li Yu <bingtian.ly@taobao.com>
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index e886e2f..b2f8ada 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -2169,8 +2169,6 @@ static void tcp_enter_frto_loss(struct sock *sk,
> int allowed_segments, int flag)
> /* For some reason this R-bit might get cleared? */
> if (TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_RETRANS)
> tp->retrans_out += tcp_skb_pcount(skb);
> - /* ...enter this if branch just for the first segment */
> - flag |= FLAG_DATA_ACKED;
The comment explicitly explains why the flag is marked for.
> } else {
> if (TCP_SKB_CB(skb)->sacked & TCPCB_RETRANS)
> tp->undo_marker = 0;
> --
> 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: a F-RTO question
From: Chao Pei @ 2012-03-28 5:27 UTC (permalink / raw)
To: Li Yu; +Cc: netdev
In-Reply-To: <4F728EC9.1050302@gmail.com>
>
>>> Hi,
>>>
>>> I have a question about tcp_process_frto(), the below source
>>> code :
>>>
>>> static int tcp_process_frto(struct sock *sk, int flag)
>>> {
>>> .....
>>>
>>> if (!before(tp->snd_una, tp->frto_highmark)) {
>>> tcp_enter_frto_loss(sk, ...);
>>> return 1;
>>> }
>>>
>>> .....
>>>
>>> }
>>>
>>> As my understanding, the tp->frto_highmark likes tp->high_seq,
>>> it saves the seqno SND_NXT when a TCP connection enters F-RTO phase,
>>> is it the variable "recovery" in NewReno? So I think that if snd_una is
>>> equal with or after frto_highmark, which means peer ack new data, so
>>> why we enter Loss state here?
>>>
>>> Thanks!
>>>
>>> Yu
>>>
>>>
>>
>> If snd_una advances to frto_highmark, it is likely that the hole was
>> filled by the retransimitted packet, which means the original packet
>> was likely to have been lost.
>> So, we should enter loss state.
>>
>
> I do not agree with it, if snd_una advanced to frto_highmark, which means
> peer acks whole window of data instead of just one segment, and
> we can not make sure that reason of peer sends ack is whether it received
> original segment or retransmitted segment.
>
> Even, the reason is latter, it also means the netowrk already is
> recovered from temporarily congestion or disordered state, so we also should
> not enter loss state.
>
> Thanks
>
> Yu
>
If it is for the first reason, then the receiver should not ack the
whole rtt of packets with just one ack. Instead, it should send ack
once every second packet. So, we can almost be sure that the original
packet was lost.
As for the second question. I think since the loss is proven and was
actually detected because of the RTO timer, we should enter loss
state.
Thanks.
^ permalink raw reply
* [PATCH net] bonding: emit event when bonding changes MAC
From: Weiping Pan @ 2012-03-28 5:18 UTC (permalink / raw)
To: netdev; +Cc: fubar, andy, lwang, linux-kernel, Weiping Pan
When a bonding device is configured with fail_over_mac=active,
we expect to see the MAC address of the new active slave as the source MAC
address after failover. But we see that the source MAC address is the MAC
address of previous active slave.
Emit NETDEV_CHANGEADDR event when bonding changes its MAC address, in order
to let arp_netdev_event flush neighbour cache and route cache.
How to reproduce this bug ?
-----------hostB----------------
hostA ----- switch ---|-- eth0--bond0(192.168.100.2/24)|
(192.168.100.1/24 \--|-- eth1-/ |
--------------------------------
1 on hostB,
modprobe bonding mode=1 miimon=500 fail_over_mac=active downdelay=1000
num_grat_arp=1
ifconfig bond0 192.168.100.2/24 up
ifenslave bond0 eth0
ifenslave bond0 eth1
then eth0 is the active slave, and MAC of bond0 is MAC of eth0.
2 on hostA, ping 192.168.100.2
3 on hostB,
tcpdump -i bond0 -p icmp -XXX
you will see bond0 uses MAC of eth0 as source MAC in icmp reply.
4 on hostB,
ifconfig eth0 down
tcpdump -i bond0 -p icmp -XXX (just keep it running in step 3)
you will see first bond0 uses MAC of eth1 as source MAC in icmp
reply, then it will use MAC of eth0 as source MAC.
Signed-off-by: Weiping Pan <wpan@redhat.com>
---
drivers/net/bonding/bond_main.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index b920d82..a20b585 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -892,9 +892,15 @@ static void bond_do_fail_over_mac(struct bonding *bond,
switch (bond->params.fail_over_mac) {
case BOND_FOM_ACTIVE:
- if (new_active)
+ if (new_active) {
memcpy(bond->dev->dev_addr, new_active->dev->dev_addr,
new_active->dev->addr_len);
+ write_unlock_bh(&bond->curr_slave_lock);
+ read_unlock(&bond->lock);
+ call_netdevice_notifiers(NETDEV_CHANGEADDR, bond->dev);
+ read_lock(&bond->lock);
+ write_lock_bh(&bond->curr_slave_lock);
+ }
break;
case BOND_FOM_FOLLOW:
/*
--
1.7.4
^ permalink raw reply related
* [PATCH] tcp: remove useless update for flag parameter in tcp_enter_frto_loss()
From: Li Yu @ 2012-03-28 4:23 UTC (permalink / raw)
To: netdev
It seem that we forget remove below two lines after copying code :)
This update never impacts others.
Sorry for last mail with legal notices improperly, I used wrong
mail.
Signed-off-by Li Yu <bingtian.ly@taobao.com>
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e886e2f..b2f8ada 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2169,8 +2169,6 @@ static void tcp_enter_frto_loss(struct sock *sk,
int allowed_segments, int flag)
/* For some reason this R-bit might get cleared? */
if (TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_RETRANS)
tp->retrans_out += tcp_skb_pcount(skb);
- /* ...enter this if branch just for the first segment */
- flag |= FLAG_DATA_ACKED;
} else {
if (TCP_SKB_CB(skb)->sacked & TCPCB_RETRANS)
tp->undo_marker = 0;
^ permalink raw reply related
* Re: [PATCH] tcp: remove useless update for flag parameter in tcp_enter_frto_loss()
From: David Miller @ 2012-03-28 4:17 UTC (permalink / raw)
To: bingtian.ly; +Cc: netdev
In-Reply-To: <4F728CE3.9010402@taobao.com>
From: Li Yu <bingtian.ly@taobao.com>
Date: Wed, 28 Mar 2012 12:00:35 +0800
> This email (including any attachments) is confidential and may be legally privileged.
Do not post to the mailing list with legal notices such as this, not
only are they annoying, they are completely pointless when used on
a public mailing list.
I am completely ignoring your patches until you post them properly,
without these annoying notices attached.
^ permalink raw reply
* [PATCH] tcp: remove useless update for flag parameter in tcp_enter_frto_loss()
From: Li Yu @ 2012-03-28 4:00 UTC (permalink / raw)
To: netdev
It seem that we forget remove below two lines after copying code :)
This update never impacts others.
Signed-off-by Li Yu <bingtian.ly@taobao.com>
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e886e2f..b2f8ada 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2169,8 +2169,6 @@ static void tcp_enter_frto_loss(struct sock *sk,
int allowed_segments, int flag)
/* For some reason this R-bit might get cleared? */
if (TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_RETRANS)
tp->retrans_out += tcp_skb_pcount(skb);
- /* ...enter this if branch just for the first segment */
- flag |= FLAG_DATA_ACKED;
} else {
if (TCP_SKB_CB(skb)->sacked & TCPCB_RETRANS)
tp->undo_marker = 0;
________________________________
This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you.
本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。
^ permalink raw reply related
* Re: a F-RTO question
From: Li Yu @ 2012-03-28 4:08 UTC (permalink / raw)
To: Chao Pei; +Cc: netdev
In-Reply-To: <CAJkE24+qgK4_cGtiEi6hWDFS2EVYPajHY3pigwh_RqguwsedNg@mail.gmail.com>
于 2012年03月28日 11:49, Chao Pei 写道:
>> Hi,
>>
>> I have a question about tcp_process_frto(), the below source
>> code :
>>
>> static int tcp_process_frto(struct sock *sk, int flag)
>> {
>> .....
>>
>> if (!before(tp->snd_una, tp->frto_highmark)) {
>> tcp_enter_frto_loss(sk, ...);
>> return 1;
>> }
>>
>> .....
>>
>> }
>>
>> As my understanding, the tp->frto_highmark likes tp->high_seq,
>> it saves the seqno SND_NXT when a TCP connection enters F-RTO phase,
>> is it the variable "recovery" in NewReno? So I think that if snd_una is
>> equal with or after frto_highmark, which means peer ack new data, so
>> why we enter Loss state here?
>>
>> Thanks!
>>
>> Yu
>>
>>
>
> If snd_una advances to frto_highmark, it is likely that the hole was
> filled by the retransimitted packet, which means the original packet
> was likely to have been lost.
> So, we should enter loss state.
>
I do not agree with it, if snd_una advanced to frto_highmark, which
means peer acks whole window of data instead of just one segment, and
we can not make sure that reason of peer sends ack is whether it
received original segment or retransmitted segment.
Even, the reason is latter, it also means the netowrk already is
recovered from temporarily congestion or disordered state, so we also
should not enter loss state.
Thanks
Yu
^ permalink raw reply
* Re: a F-RTO question
From: Chao Pei @ 2012-03-28 3:49 UTC (permalink / raw)
To: Li Yu; +Cc: netdev
In-Reply-To: <4F7281ED.1060603@gmail.com>
> Hi,
>
> I have a question about tcp_process_frto(), the below source
> code :
>
> static int tcp_process_frto(struct sock *sk, int flag)
> {
> .....
>
> if (!before(tp->snd_una, tp->frto_highmark)) {
> tcp_enter_frto_loss(sk, ...);
> return 1;
> }
>
> .....
>
> }
>
> As my understanding, the tp->frto_highmark likes tp->high_seq,
> it saves the seqno SND_NXT when a TCP connection enters F-RTO phase,
> is it the variable "recovery" in NewReno? So I think that if snd_una is
> equal with or after frto_highmark, which means peer ack new data, so
> why we enter Loss state here?
>
> Thanks!
>
> Yu
>
>
If snd_una advances to frto_highmark, it is likely that the hole was
filled by the retransimitted packet, which means the original packet
was likely to have been lost.
So, we should enter loss state.
^ permalink raw reply
* a F-RTO question
From: Li Yu @ 2012-03-28 3:13 UTC (permalink / raw)
To: netdev
Hi,
I have a question about tcp_process_frto(), the below source
code :
static int tcp_process_frto(struct sock *sk, int flag)
{
.....
if (!before(tp->snd_una, tp->frto_highmark)) {
tcp_enter_frto_loss(sk, ...);
return 1;
}
.....
}
As my understanding, the tp->frto_highmark likes tp->high_seq,
it saves the seqno SND_NXT when a TCP connection enters F-RTO phase,
is it the variable "recovery" in NewReno? So I think that if snd_una is
equal with or after frto_highmark, which means peer ack new data, so
why we enter Loss state here?
Thanks!
Yu
^ permalink raw reply
* RE: [PATCH net-next 2/5] r8169: add csi_opt
From: hayeswang @ 2012-03-28 2:52 UTC (permalink / raw)
To: 'Francois Romieu'; +Cc: netdev, linux-kernel
In-Reply-To: <20120327225437.GC22177@electric-eye.fr.zoreil.com>
Francois Romieu [mailto:romieu@fr.zoreil.com]
[...]
> > -static void rtl_csi_access_enable_2(void __iomem *ioaddr)
> > +static void __devinit rtl_init_csi_ops(struct rtl8169_private *tp)
> > {
> > - rtl_csi_access_enable(ioaddr, 0x27000000);
> > + struct csi_ops *ops = &tp->csi_ops;
> > +
> > + switch (tp->mac_version) {
> > + default:
> > + ops->write = r8169_csi_write;
> > + ops->read = r8169_csi_read;
> > + break;
> > + }
> > }
> >
> > struct ephy_info {
> [...]
> > @@ -6199,6 +6267,7 @@ rtl_init_one(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> > rtl_init_mdio_ops(tp);
> > rtl_init_pll_power_ops(tp);
> > rtl_init_jumbo_ops(tp);
> > + rtl_init_csi_ops(tp);
> >
> > rtl8169_print_mac_version(tp);
>
> It will enable the CSI read/write functions where they
> previously weren't.
>
> Is it really supposed to behave this way ?
>
> Thanks.
>
It seems to be fine, but I would modify them. Thanks.
Best Regards,
Hayes
^ 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