* [PATCH net-next 2/3] net/mlx4_core: Cache line EQE size support
From: Or Gerlitz @ 2014-09-18 8:51 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Amir Vadai, Ido Shamay, Jack Morgenstein, Or Gerlitz
In-Reply-To: <1411030261-12145-1-git-send-email-ogerlitz@mellanox.com>
From: Ido Shamay <idos@mellanox.com>
Enable mlx4 interrupt handler to work with EQE stride feature,
The feature may be enabled when cache line is bigger than 64B.
The EQE size will then be the cache line size, and the context
segment resides in [0-31] offset.
Signed-off-by: Ido Shamay <idos@mellanox.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/eq.c | 30 +++++++++++++++++++-----------
1 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/eq.c b/drivers/net/ethernet/mellanox/mlx4/eq.c
index 2a004b3..a49c9d1 100644
--- a/drivers/net/ethernet/mellanox/mlx4/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/eq.c
@@ -101,21 +101,24 @@ static void eq_set_ci(struct mlx4_eq *eq, int req_not)
mb();
}
-static struct mlx4_eqe *get_eqe(struct mlx4_eq *eq, u32 entry, u8 eqe_factor)
+static struct mlx4_eqe *get_eqe(struct mlx4_eq *eq, u32 entry, u8 eqe_factor,
+ u8 eqe_size)
{
/* (entry & (eq->nent - 1)) gives us a cyclic array */
- unsigned long offset = (entry & (eq->nent - 1)) * (MLX4_EQ_ENTRY_SIZE << eqe_factor);
- /* CX3 is capable of extending the EQE from 32 to 64 bytes.
- * When this feature is enabled, the first (in the lower addresses)
+ unsigned long offset = (entry & (eq->nent - 1)) * eqe_size;
+ /* CX3 is capable of extending the EQE from 32 to 64 bytes with
+ * strides of 64B,128B and 256B.
+ * When 64B EQE is used, the first (in the lower addresses)
* 32 bytes in the 64 byte EQE are reserved and the next 32 bytes
* contain the legacy EQE information.
+ * In all other cases, the first 32B contains the legacy EQE info.
*/
return eq->page_list[offset / PAGE_SIZE].buf + (offset + (eqe_factor ? MLX4_EQ_ENTRY_SIZE : 0)) % PAGE_SIZE;
}
-static struct mlx4_eqe *next_eqe_sw(struct mlx4_eq *eq, u8 eqe_factor)
+static struct mlx4_eqe *next_eqe_sw(struct mlx4_eq *eq, u8 eqe_factor, u8 size)
{
- struct mlx4_eqe *eqe = get_eqe(eq, eq->cons_index, eqe_factor);
+ struct mlx4_eqe *eqe = get_eqe(eq, eq->cons_index, eqe_factor, size);
return !!(eqe->owner & 0x80) ^ !!(eq->cons_index & eq->nent) ? NULL : eqe;
}
@@ -459,8 +462,9 @@ static int mlx4_eq_int(struct mlx4_dev *dev, struct mlx4_eq *eq)
enum slave_port_gen_event gen_event;
unsigned long flags;
struct mlx4_vport_state *s_info;
+ int eqe_size = dev->caps.eqe_size;
- while ((eqe = next_eqe_sw(eq, dev->caps.eqe_factor))) {
+ while ((eqe = next_eqe_sw(eq, dev->caps.eqe_factor, eqe_size))) {
/*
* Make sure we read EQ entry contents after we've
* checked the ownership bit.
@@ -894,8 +898,10 @@ static int mlx4_create_eq(struct mlx4_dev *dev, int nent,
eq->dev = dev;
eq->nent = roundup_pow_of_two(max(nent, 2));
- /* CX3 is capable of extending the CQE/EQE from 32 to 64 bytes */
- npages = PAGE_ALIGN(eq->nent * (MLX4_EQ_ENTRY_SIZE << dev->caps.eqe_factor)) / PAGE_SIZE;
+ /* CX3 is capable of extending the CQE/EQE from 32 to 64 bytes, with
+ * strides of 64B,128B and 256B.
+ */
+ npages = PAGE_ALIGN(eq->nent * dev->caps.eqe_size) / PAGE_SIZE;
eq->page_list = kmalloc(npages * sizeof *eq->page_list,
GFP_KERNEL);
@@ -997,8 +1003,10 @@ static void mlx4_free_eq(struct mlx4_dev *dev,
struct mlx4_cmd_mailbox *mailbox;
int err;
int i;
- /* CX3 is capable of extending the CQE/EQE from 32 to 64 bytes */
- int npages = PAGE_ALIGN((MLX4_EQ_ENTRY_SIZE << dev->caps.eqe_factor) * eq->nent) / PAGE_SIZE;
+ /* CX3 is capable of extending the CQE/EQE from 32 to 64 bytes, with
+ * strides of 64B,128B and 256B
+ */
+ int npages = PAGE_ALIGN(dev->caps.eqe_size * eq->nent) / PAGE_SIZE;
mailbox = mlx4_alloc_cmd_mailbox(dev);
if (IS_ERR(mailbox))
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 3/3] net/mlx4_en: Add mlx4_en_get_cqe helper
From: Or Gerlitz @ 2014-09-18 8:51 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Amir Vadai, Ido Shamay, Jack Morgenstein, Or Gerlitz
In-Reply-To: <1411030261-12145-1-git-send-email-ogerlitz@mellanox.com>
From: Ido Shamay <idos@mellanox.com>
This function derives the base address of the CQE from the CQE size,
and calculates the real CQE context segment in it from the factor
(this is like before). Before this change the code used the factor to
calculate the base address of the CQE as well.
The factor indicates in which segment of the cqe stride the cqe information
is located. For 32-byte strides, the segment is 0, and for 64 byte strides,
the segment is 1 (bytes 32..63). Using the factor was ok as long as we had
only 32 and 64 byte strides. However, with larger strides, the factor is zero,
and so cannot be used to calculate the base of the CQE.
The helper uses the same method of CQE buffer pulling made by all other
components that reads the CQE buffer (mlx4_ib driver and libmlx4).
Signed-off-by: Ido Shamay <idos@mellanox.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 1 +
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 4 ++--
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 4 ++--
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 6 ++++++
4 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index abddcf8..f3032fe 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -2459,6 +2459,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
}
priv->rx_ring_num = prof->rx_ring_num;
priv->cqe_factor = (mdev->dev->caps.cqe_size == 64) ? 1 : 0;
+ priv->cqe_size = mdev->dev->caps.cqe_size;
priv->mac_index = -1;
priv->msg_enable = MLX4_EN_MSG_LEVEL;
spin_lock_init(&priv->stats_lock);
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 14686b6..a33048e 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -671,7 +671,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
* descriptor offset can be deduced from the CQE index instead of
* reading 'cqe->index' */
index = cq->mcq.cons_index & ring->size_mask;
- cqe = &cq->buf[(index << factor) + factor];
+ cqe = mlx4_en_get_cqe(cq->buf, index, priv->cqe_size) + factor;
/* Process all completed CQEs */
while (XNOR(cqe->owner_sr_opcode & MLX4_CQE_OWNER_MASK,
@@ -858,7 +858,7 @@ next:
++cq->mcq.cons_index;
index = (cq->mcq.cons_index) & ring->size_mask;
- cqe = &cq->buf[(index << factor) + factor];
+ cqe = mlx4_en_get_cqe(cq->buf, index, priv->cqe_size) + factor;
if (++polled == budget)
goto out;
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index bc8f51c..c44f423 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -382,7 +382,7 @@ static bool mlx4_en_process_tx_cq(struct net_device *dev,
return true;
index = cons_index & size_mask;
- cqe = &buf[(index << factor) + factor];
+ cqe = mlx4_en_get_cqe(buf, index, priv->cqe_size) + factor;
ring_index = ring->cons & size_mask;
stamp_index = ring_index;
@@ -430,7 +430,7 @@ static bool mlx4_en_process_tx_cq(struct net_device *dev,
++cons_index;
index = cons_index & size_mask;
- cqe = &buf[(index << factor) + factor];
+ cqe = mlx4_en_get_cqe(buf, index, priv->cqe_size) + factor;
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 3de41be..e3d71c3 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -542,6 +542,7 @@ struct mlx4_en_priv {
unsigned max_mtu;
int base_qpn;
int cqe_factor;
+ int cqe_size;
struct mlx4_en_rss_map rss_map;
__be32 ctrl_flags;
@@ -612,6 +613,11 @@ struct mlx4_mac_entry {
struct rcu_head rcu;
};
+static inline struct mlx4_cqe *mlx4_en_get_cqe(void *buf, int idx, int cqe_sz)
+{
+ return buf + idx * cqe_sz;
+}
+
#ifdef CONFIG_NET_RX_BUSY_POLL
static inline void mlx4_en_cq_init_lock(struct mlx4_en_cq *cq)
{
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 0/3] mlx4: CQE/EQE stride support
From: Or Gerlitz @ 2014-09-18 8:50 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Amir Vadai, Ido Shamay, Or Gerlitz
This series from Ido Shamay is intended for archs having
cache line larger then 64 bytes.
Since our CQE/EQEs are generally 64B in those systems, HW will write
twice to the same cache line consecutively, causing pipe locks due to
he hazard prevention mechanism. For elements in a cyclic buffer, writes
are consecutive, so entries smaller than a cache line should be
avoided, especially if they are written at a high rate.
Reduce consecutive writes to same cache line in CQs/EQs, by allowing the
driver to increase the distance between entries so that each will reside
in a different cache line.
Or.
Ido Shamay (3):
net/mlx4_core: Enable CQE/EQE stride support
net/mlx4_core: Cache line EQE size support
net/mlx4_en: Add mlx4_en_get_cqe helper
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 1 +
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 4 +-
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 4 +-
drivers/net/ethernet/mellanox/mlx4/eq.c | 30 +++++++----
drivers/net/ethernet/mellanox/mlx4/fw.c | 38 ++++++++++++++-
drivers/net/ethernet/mellanox/mlx4/fw.h | 2 +
drivers/net/ethernet/mellanox/mlx4/main.c | 61 +++++++++++++++++++++++-
drivers/net/ethernet/mellanox/mlx4/mlx4.h | 3 +
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 6 ++
include/linux/mlx4/device.h | 11 +++-
10 files changed, 138 insertions(+), 22 deletions(-)
^ permalink raw reply
* [PATCH net-next 1/3] net/mlx4_core: Enable CQE/EQE stride support
From: Or Gerlitz @ 2014-09-18 8:50 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Amir Vadai, Ido Shamay, Jack Morgenstein, Or Gerlitz
In-Reply-To: <1411030261-12145-1-git-send-email-ogerlitz@mellanox.com>
From: Ido Shamay <idos@mellanox.com>
This feature is intended for archs having cache line larger then 64B.
Since our CQE/EQEs are generally 64B in those systems, HW will write
twice to the same cache line consecutively, causing pipe locks due to
he hazard prevention mechanism. For elements in a cyclic buffer, writes
are consecutive, so entries smaller than a cache line should be
avoided, especially if they are written at a high rate.
Reduce consecutive writes to same cache line in CQs/EQs, by allowing the
driver to increase the distance between entries so that each will reside
in a different cache line. Until the introduction of this feature, there
were two types of CQE/EQE:
1. 32B stride and context in the [0-31] segment
2. 64B stride and context in the [32-63] segment
This feature introduces two additional types:
3. 128B stride and context in the [0-31] segment (128B cache line)
4. 256B stride and context in the [0-31] segment (256B cache line)
Modify the mlx4_core driver to query the device for the CQE/EQE cache
line stride capability and to enable that capability when the host
cache line size is larger than 64 bytes (supported cache lines are
128B and 256B).
The mlx4 IB driver and libmlx4 need not be aware of this change. The PF
context behaviour is changed to require this change in VF drivers
running on such archs.
Signed-off-by: Ido Shamay <idos@mellanox.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/fw.c | 38 +++++++++++++++++-
drivers/net/ethernet/mellanox/mlx4/fw.h | 2 +
drivers/net/ethernet/mellanox/mlx4/main.c | 61 ++++++++++++++++++++++++++++-
drivers/net/ethernet/mellanox/mlx4/mlx4.h | 3 +
include/linux/mlx4/device.h | 11 ++++-
5 files changed, 108 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 494753e..13b2e4a 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -137,7 +137,9 @@ static void dump_dev_cap_flags2(struct mlx4_dev *dev, u64 flags)
[8] = "Dynamic QP updates support",
[9] = "Device managed flow steering IPoIB support",
[10] = "TCP/IP offloads/flow-steering for VXLAN support",
- [11] = "MAD DEMUX (Secure-Host) support"
+ [11] = "MAD DEMUX (Secure-Host) support",
+ [12] = "Large cache line (>64B) CQE stride support",
+ [13] = "Large cache line (>64B) EQE stride support"
};
int i;
@@ -557,6 +559,7 @@ int mlx4_QUERY_DEV_CAP(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
#define QUERY_DEV_CAP_FLOW_STEERING_IPOIB_OFFSET 0x74
#define QUERY_DEV_CAP_FLOW_STEERING_RANGE_EN_OFFSET 0x76
#define QUERY_DEV_CAP_FLOW_STEERING_MAX_QP_OFFSET 0x77
+#define QUERY_DEV_CAP_CQ_EQ_CACHE_LINE_STRIDE 0x7a
#define QUERY_DEV_CAP_RDMARC_ENTRY_SZ_OFFSET 0x80
#define QUERY_DEV_CAP_QPC_ENTRY_SZ_OFFSET 0x82
#define QUERY_DEV_CAP_AUX_ENTRY_SZ_OFFSET 0x84
@@ -733,6 +736,11 @@ int mlx4_QUERY_DEV_CAP(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
dev_cap->max_rq_sg = field;
MLX4_GET(size, outbox, QUERY_DEV_CAP_MAX_DESC_SZ_RQ_OFFSET);
dev_cap->max_rq_desc_sz = size;
+ MLX4_GET(field, outbox, QUERY_DEV_CAP_CQ_EQ_CACHE_LINE_STRIDE);
+ if (field & (1 << 6))
+ dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_CQE_STRIDE;
+ if (field & (1 << 7))
+ dev_cap->flags2 |= MLX4_DEV_CAP_FLAG2_EQE_STRIDE;
MLX4_GET(dev_cap->bmme_flags, outbox,
QUERY_DEV_CAP_BMME_FLAGS_OFFSET);
@@ -1376,6 +1384,7 @@ int mlx4_INIT_HCA(struct mlx4_dev *dev, struct mlx4_init_hca_param *param)
#define INIT_HCA_CQC_BASE_OFFSET (INIT_HCA_QPC_OFFSET + 0x30)
#define INIT_HCA_LOG_CQ_OFFSET (INIT_HCA_QPC_OFFSET + 0x37)
#define INIT_HCA_EQE_CQE_OFFSETS (INIT_HCA_QPC_OFFSET + 0x38)
+#define INIT_HCA_EQE_CQE_STRIDE_OFFSET (INIT_HCA_QPC_OFFSET + 0x3b)
#define INIT_HCA_ALTC_BASE_OFFSET (INIT_HCA_QPC_OFFSET + 0x40)
#define INIT_HCA_AUXC_BASE_OFFSET (INIT_HCA_QPC_OFFSET + 0x50)
#define INIT_HCA_EQC_BASE_OFFSET (INIT_HCA_QPC_OFFSET + 0x60)
@@ -1452,11 +1461,25 @@ int mlx4_INIT_HCA(struct mlx4_dev *dev, struct mlx4_init_hca_param *param)
if (dev->caps.flags & MLX4_DEV_CAP_FLAG_64B_CQE) {
*(inbox + INIT_HCA_EQE_CQE_OFFSETS / 4) |= cpu_to_be32(1 << 30);
dev->caps.cqe_size = 64;
- dev->caps.userspace_caps |= MLX4_USER_DEV_CAP_64B_CQE;
+ dev->caps.userspace_caps |= MLX4_USER_DEV_CAP_LARGE_CQE;
} else {
dev->caps.cqe_size = 32;
}
+ /* CX3 is capable of extending CQEs\EQEs to strides larger than 64B */
+ if ((dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_EQE_STRIDE) &&
+ (dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_CQE_STRIDE)) {
+ dev->caps.eqe_size = cache_line_size();
+ dev->caps.cqe_size = cache_line_size();
+ dev->caps.eqe_factor = 0;
+ MLX4_PUT(inbox, (u8)((ilog2(dev->caps.eqe_size) - 5) << 4 |
+ (ilog2(dev->caps.eqe_size) - 5)),
+ INIT_HCA_EQE_CQE_STRIDE_OFFSET);
+
+ /* User still need to know to support CQE > 32B */
+ dev->caps.userspace_caps |= MLX4_USER_DEV_CAP_LARGE_CQE;
+ }
+
/* QPC/EEC/CQC/EQC/RDMARC attributes */
MLX4_PUT(inbox, param->qpc_base, INIT_HCA_QPC_BASE_OFFSET);
@@ -1616,6 +1639,17 @@ int mlx4_QUERY_HCA(struct mlx4_dev *dev,
if (byte_field & 0x40) /* 64-bytes cqe enabled */
param->dev_cap_enabled |= MLX4_DEV_CAP_64B_CQE_ENABLED;
+ /* CX3 is capable of extending CQEs\EQEs to strides larger than 64B */
+ MLX4_GET(byte_field, outbox, INIT_HCA_EQE_CQE_STRIDE_OFFSET);
+ if (byte_field) {
+ param->dev_cap_enabled |= MLX4_DEV_CAP_64B_EQE_ENABLED;
+ param->dev_cap_enabled |= MLX4_DEV_CAP_64B_CQE_ENABLED;
+ param->cqe_size = 1 << ((byte_field &
+ MLX4_CQE_SIZE_MASK_STRIDE) + 5);
+ param->eqe_size = 1 << (((byte_field &
+ MLX4_EQE_SIZE_MASK_STRIDE) >> 4) + 5);
+ }
+
/* TPT attributes */
MLX4_GET(param->dmpt_base, outbox, INIT_HCA_DMPT_BASE_OFFSET);
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.h b/drivers/net/ethernet/mellanox/mlx4/fw.h
index 1fce03e..9b835ae 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.h
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.h
@@ -178,6 +178,8 @@ struct mlx4_init_hca_param {
u8 uar_page_sz; /* log pg sz in 4k chunks */
u8 steering_mode; /* for QUERY_HCA */
u64 dev_cap_enabled;
+ u16 cqe_size; /* For use only when CQE stride feature enabled */
+ u16 eqe_size; /* For use only when EQE stride feature enabled */
};
struct mlx4_init_ib_param {
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 7e2d5d5..1f10023 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -104,7 +104,8 @@ module_param(enable_64b_cqe_eqe, bool, 0444);
MODULE_PARM_DESC(enable_64b_cqe_eqe,
"Enable 64 byte CQEs/EQEs when the FW supports this (default: True)");
-#define PF_CONTEXT_BEHAVIOUR_MASK MLX4_FUNC_CAP_64B_EQE_CQE
+#define PF_CONTEXT_BEHAVIOUR_MASK (MLX4_FUNC_CAP_64B_EQE_CQE | \
+ MLX4_FUNC_CAP_EQE_CQE_STRIDE)
static char mlx4_version[] =
DRV_NAME ": Mellanox ConnectX core driver v"
@@ -196,6 +197,40 @@ static void mlx4_set_port_mask(struct mlx4_dev *dev)
dev->caps.port_mask[i] = dev->caps.port_type[i];
}
+static void mlx4_enable_cqe_eqe_stride(struct mlx4_dev *dev)
+{
+ struct mlx4_caps *dev_cap = &dev->caps;
+
+ /* FW not supporting or cancelled by user */
+ if (!(dev_cap->flags2 & MLX4_DEV_CAP_FLAG2_EQE_STRIDE) ||
+ !(dev_cap->flags2 & MLX4_DEV_CAP_FLAG2_CQE_STRIDE))
+ return;
+
+ /* Must have 64B CQE_EQE enabled by FW to use bigger stride
+ * When FW has NCSI it may decide not to report 64B CQE/EQEs
+ */
+ if (!(dev_cap->flags & MLX4_DEV_CAP_FLAG_64B_EQE) ||
+ !(dev_cap->flags & MLX4_DEV_CAP_FLAG_64B_CQE)) {
+ dev_cap->flags2 &= ~MLX4_DEV_CAP_FLAG2_CQE_STRIDE;
+ dev_cap->flags2 &= ~MLX4_DEV_CAP_FLAG2_EQE_STRIDE;
+ return;
+ }
+
+ if (cache_line_size() == 128 || cache_line_size() == 256) {
+ mlx4_dbg(dev, "Enabling CQE stride cacheLine supported\n");
+ /* Changing the real data inside CQE size to 32B */
+ dev_cap->flags &= ~MLX4_DEV_CAP_FLAG_64B_CQE;
+ dev_cap->flags &= ~MLX4_DEV_CAP_FLAG_64B_EQE;
+
+ if (mlx4_is_master(dev))
+ dev_cap->function_caps |= MLX4_FUNC_CAP_EQE_CQE_STRIDE;
+ } else {
+ mlx4_dbg(dev, "Disabling CQE stride cacheLine unsupported\n");
+ dev_cap->flags2 &= ~MLX4_DEV_CAP_FLAG2_CQE_STRIDE;
+ dev_cap->flags2 &= ~MLX4_DEV_CAP_FLAG2_EQE_STRIDE;
+ }
+}
+
static int mlx4_dev_cap(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
{
int err;
@@ -390,6 +425,14 @@ static int mlx4_dev_cap(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
dev->caps.flags &= ~MLX4_DEV_CAP_FLAG_64B_CQE;
dev->caps.flags &= ~MLX4_DEV_CAP_FLAG_64B_EQE;
}
+
+ if (dev_cap->flags2 &
+ (MLX4_DEV_CAP_FLAG2_CQE_STRIDE |
+ MLX4_DEV_CAP_FLAG2_EQE_STRIDE)) {
+ mlx4_warn(dev, "Disabling EQE/CQE stride per user request\n");
+ dev_cap->flags2 &= ~MLX4_DEV_CAP_FLAG2_CQE_STRIDE;
+ dev_cap->flags2 &= ~MLX4_DEV_CAP_FLAG2_EQE_STRIDE;
+ }
}
if ((dev->caps.flags &
@@ -397,6 +440,9 @@ static int mlx4_dev_cap(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
mlx4_is_master(dev))
dev->caps.function_caps |= MLX4_FUNC_CAP_64B_EQE_CQE;
+ if (!mlx4_is_slave(dev))
+ mlx4_enable_cqe_eqe_stride(dev);
+
return 0;
}
@@ -724,11 +770,22 @@ static int mlx4_slave_cap(struct mlx4_dev *dev)
if (hca_param.dev_cap_enabled & MLX4_DEV_CAP_64B_CQE_ENABLED) {
dev->caps.cqe_size = 64;
- dev->caps.userspace_caps |= MLX4_USER_DEV_CAP_64B_CQE;
+ dev->caps.userspace_caps |= MLX4_USER_DEV_CAP_LARGE_CQE;
} else {
dev->caps.cqe_size = 32;
}
+ if (hca_param.dev_cap_enabled & MLX4_DEV_CAP_EQE_STRIDE_ENABLED) {
+ dev->caps.eqe_size = hca_param.eqe_size;
+ dev->caps.eqe_factor = 0;
+ }
+
+ if (hca_param.dev_cap_enabled & MLX4_DEV_CAP_CQE_STRIDE_ENABLED) {
+ dev->caps.cqe_size = hca_param.cqe_size;
+ /* User still need to know when CQE > 32B */
+ dev->caps.userspace_caps |= MLX4_USER_DEV_CAP_LARGE_CQE;
+ }
+
dev->caps.flags2 &= ~MLX4_DEV_CAP_FLAG2_TS;
mlx4_warn(dev, "Timestamping is not supported in slave mode\n");
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
index b508c78..de10dbb 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
@@ -285,6 +285,9 @@ struct mlx4_icm_table {
#define MLX4_MPT_STATUS_SW 0xF0
#define MLX4_MPT_STATUS_HW 0x00
+#define MLX4_CQE_SIZE_MASK_STRIDE 0x3
+#define MLX4_EQE_SIZE_MASK_STRIDE 0x30
+
/*
* Must be packed because mtt_seg is 64 bits but only aligned to 32 bits.
*/
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index 1befd8d..7bcefe7 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -185,19 +185,24 @@ enum {
MLX4_DEV_CAP_FLAG2_DMFS_IPOIB = 1LL << 9,
MLX4_DEV_CAP_FLAG2_VXLAN_OFFLOADS = 1LL << 10,
MLX4_DEV_CAP_FLAG2_MAD_DEMUX = 1LL << 11,
+ MLX4_DEV_CAP_FLAG2_CQE_STRIDE = 1LL << 12,
+ MLX4_DEV_CAP_FLAG2_EQE_STRIDE = 1LL << 13
};
enum {
MLX4_DEV_CAP_64B_EQE_ENABLED = 1LL << 0,
- MLX4_DEV_CAP_64B_CQE_ENABLED = 1LL << 1
+ MLX4_DEV_CAP_64B_CQE_ENABLED = 1LL << 1,
+ MLX4_DEV_CAP_CQE_STRIDE_ENABLED = 1LL << 2,
+ MLX4_DEV_CAP_EQE_STRIDE_ENABLED = 1LL << 3
};
enum {
- MLX4_USER_DEV_CAP_64B_CQE = 1L << 0
+ MLX4_USER_DEV_CAP_LARGE_CQE = 1L << 0
};
enum {
- MLX4_FUNC_CAP_64B_EQE_CQE = 1L << 0
+ MLX4_FUNC_CAP_64B_EQE_CQE = 1L << 0,
+ MLX4_FUNC_CAP_EQE_CQE_STRIDE = 1L << 1
};
--
1.7.1
^ permalink raw reply related
* Re: [GIT PULL v2 00/15] Second Round of IPVS Updates for v3.18
From: Pablo Neira Ayuso @ 2014-09-18 9:03 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov
In-Reply-To: <1410999961-7975-1-git-send-email-horms@verge.net.au>
On Thu, Sep 18, 2014 at 09:25:46AM +0900, Simon Horman wrote:
> Hi Pablo,
>
> please consider these IPVS updates for v3.18.
>
> I hope that v2 of this pull request addresses the issues you raised
> in v1. In particular "ipvs: use correct address family in scheduler logs"
> patch consolidates what was previously 7 patches. And I have provided
> a longer description: I hope the tone is closer to what you need.
>
> This pull requests makes the following changes:
>
> * Add simple weighted fail-over scheduler.
> - Unlike other IPVS schedulers this offers fail-over rather than load
> balancing. Connections are directed to the appropriate server based
> solely on highest weight value and server availability.
> - Thanks to Kenny Mathis
>
> * Support IPv6 real servers in IPv4 virtual-services and vice versa
> - This feature is supported in conjunction with the tunnel (IPIP)
> forwarding mechanism. That is, IPv4 may be forwarded in IPv6 and
> vice versa.
> - The motivation for this is to allow more flexibility in the
> choice of IP version offered by both virtual-servers and
> real-servers as they no longer need to match: An IPv4 connection from an
> end-user may be forwarded to a real-server using IPv6 and vice versa.
> - Further work need to be done to support this feature in conjunction
> with connection synchronisation. For now such configurations are
> not allowed.
> - This change includes update to netlink protocol, adding a new
> destination address family attribute. And the necessary changes
> to plumb this information throughout IPVS.
> - Thanks to Alex Gartrell and Julian Anastasov
>
> The following changes since commit 0bbe80e571c7b866afd92a98edd32a969467a7a9:
>
> netfilter: masquerading needs to be independent of x_tables in Kconfig (2014-09-12 09:40:18 +0200)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git tags/ipvs2-for-v3.18
Pulled, thanks a lot Simon.
^ permalink raw reply
* Re: Figuring out how vti works
From: Steffen Klassert @ 2014-09-18 9:06 UTC (permalink / raw)
To: Joe M; +Cc: netdev@vger.kernel.org
In-Reply-To: <CAHjjW16qdT6RWuJaUd1c6k39RgcPtfsyF=V-dVowW_2UwhF_dw@mail.gmail.com>
On Wed, Sep 17, 2014 at 06:04:07PM -0500, Joe M wrote:
>
> master# echo "1" | sudo tee /proc/sys/net/ipv4/ip_forward
> 1
> master# modprobe ip_vti
> master# ipsec start
> Starting strongSwan 5.2.0 IPsec [starter]...
> master# ip tunnel add vtil mode vti local 192.168.0.11 remote
> 192.168.1.232 ikey 1 okey 1
> master# ip link set vtil up
> master# sleep 60
> master# ip route add 192.168.1.0/24 dev vtil
> master# ip xfrm state
> src 192.168.0.11 dst <client or alice or bnglr public ip>
Not sure what <client or alice or bnglr public ip> is,
but dst must match the remote tunnel endpoint i.e.
192.168.1.232 in your case.
^ permalink raw reply
* Donation Made To You
From: Brazelton, DeBorah A. @ 2014-09-18 8:46 UTC (permalink / raw)
In-Reply-To: <5265F093F714E640AC67720A83DC7E4C01D792B9584D@EX2K72.slps.SLPSROOT.ORG>
[-- Attachment #1: Type: text/plain, Size: 29 bytes --]
See attached file for details
[-- Attachment #2: From Pedro.docx --]
[-- Type: application/octet-stream, Size: 3158 bytes --]
^ permalink raw reply
* Re: Figuring out how vti works
From: Steffen Klassert @ 2014-09-18 9:20 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: Joe M
In-Reply-To: <20140918050807.GA10599@master>
On Thu, Sep 18, 2014 at 12:08:07AM -0500, Joe M wrote:
> Hello Steffen,
>
> Checking further with printk's, I can see
>
> vti_tunnel_init being called for both ip_vti0 and vtil tunnels. But,
> when vti_tunnel_xmit is called, it is called with ip_vti0 tunnel and
> not the vtil tunnel. I am not sure if I am setting the route wrong.
If you can't get traffic into the tunnel, then the routing is
likely to be wrong.
>
> master# echo "1" | sudo tee /proc/sys/net/ipv4/ip_forward
> 1
> master# modprobe ip_vti
> master# ipsec start
> Starting strongSwan 5.2.0 IPsec [starter]...
> master# ip tunnel add vtil mode vti local 192.168.0.11 remote 192.168.1.232 ikey 1 okey 1
> master# ip link set vtil up
> master# sleep 10
> master# ip route add 192.168.1.0/24 dev vtil
> master# ip route list
> default via 192.168.0.1 dev enp4s0 metric 202
> 127.0.0.0/8 dev lo scope host
> 192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.11 metric 202
> 192.168.1.0/24 dev vtil scope link
>
> ip link list
> .
> .
> .
> 13: ip_vti0@NONE: <NOARP,UP,LOWER_UP> mtu 1428 qdisc noqueue state UNKNOWN mode DEFAULT group default
> link/ipip 0.0.0.0 brd 0.0.0.0
Why is the ip_vti0 interface up? This should be down after inserting
the ip_vti module and I don't see that you've set it up with the
commands above.
Set the ip_vti0 interface down and try to find out where your
packets are getting dropped. As I said already, netstat -i and
/proc/net/xfrm_stat can help.
^ permalink raw reply
* [net-next] am2150: Update nmclan_cs.c to use update PCMCIA API
From: Jeff Kirsher @ 2014-09-18 9:33 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene, Roger Pao
Resolves compile warning about use of a deprecated function call:
drivers/net/ethernet/amd/nmclan_cs.c: In function ‘nmclan_config’:
drivers/net/ethernet/amd/nmclan_cs.c:624:3: warning: ‘pcmcia_request_exclusive_irq’ is deprecated (declared at include/pcmcia/ds.h:213) [-Wdeprecated-declarations]
ret = pcmcia_request_exclusive_irq(link, mace_interrupt);
Updates pcmcia_request_exclusive_irq() to pcmcia_request_irq().
CC: Roger Pao <rpao@paonet.org>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/amd/nmclan_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/nmclan_cs.c b/drivers/net/ethernet/amd/nmclan_cs.c
index abf3b15..5b22764 100644
--- a/drivers/net/ethernet/amd/nmclan_cs.c
+++ b/drivers/net/ethernet/amd/nmclan_cs.c
@@ -621,7 +621,7 @@ static int nmclan_config(struct pcmcia_device *link)
ret = pcmcia_request_io(link);
if (ret)
goto failed;
- ret = pcmcia_request_exclusive_irq(link, mace_interrupt);
+ ret = pcmcia_request_irq(link, mace_interrupt);
if (ret)
goto failed;
ret = pcmcia_enable_device(link);
--
1.9.3
^ permalink raw reply related
* Re: [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge
From: Toshiaki Makita @ 2014-09-18 9:47 UTC (permalink / raw)
To: vyasevic, Toshiaki Makita, Vladislav Yasevich, netdev; +Cc: shemminger, bridge
In-Reply-To: <54199753.8050608@redhat.com>
On 2014/09/17 23:14, Vlad Yasevich wrote:
> On 09/16/2014 08:25 PM, Toshiaki Makita wrote:
>> On 2014/09/17 0:00, Vlad Yasevich wrote:
>>> On 09/16/2014 10:39 AM, Toshiaki Makita wrote:
>>>> (14/09/16 (火) 22:31), Vlad Yasevich wrote:
>>>>> On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
>>>>>> On 2014/09/16 0:19, Vlad Yasevich wrote:
>>>>>>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>>>>>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>>>>>>> If the user configures vlan devices on top of the bridge,
>>>>>>>>> automatically set up filter entries for it as long as
>>>>>>>>> bridge vlan protocol matches that of the vlan.
>>>>>>>>> This allows the user to atomatically receive vlan traffic
>>>>>>>>> for the vlans that are convifgured.
>>>>>>>>
>>>>>>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>>>>>>> interfaces and filter settings.
>>>>>>>> Can we automatically change filters when setting vlan_proto?
>>>>>>>>
>>>>>>>
>>>>>>> I thought we already do that in br_vlan_set_proto()? Nothing
>>>>>>> here introduces any new kinds of issue with that code.
>>>>>>
>>>>>> I'm referring to a case like this:
>>>>>> 1. create br0.10 (802.1ad)
>>>>>> 2. change br->vlan_proto into 88a8
>>>>>>
>>>>>> When creating br0.10 (1), br->vlan_proto is 8100 and different from
>>>>>> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
>>>>>> After changing br->vlan_proto (2), we might expect vlan 10 is not
>>>>>> filtered on br0, but it will be filtered.
>>>>>
>>>>> Ok, I see what you mean. This one is a bit tough. Our options are:
>>>>> 1) Return an error when configuring br0.10. This might break user-space. Not good.
>>>>> 2) Ignore protocol when crating the filter. This is not good either as the user
>>>>> may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
>>>>> 3) Re-implement .1ad support per-vlan instead of per-bridge.
>>>>>
>>>>> You see another other alternatives?
>>>>
>>>> We might be able to configure filterings on changing vlan_proto.
>>>> 4) Memorize different protocol's filtering requests in
>>>> br_vlan_rx_add_vid() and use them when switching vlan_proto.
>>>
>>> If we do this, we might as well take it one small step further and make per-vlan protocol
>>> support.
>>>
>>>> 5) Scan vlan devices on bridge device when changing vlan_proto.
>>>>
>>>
>>> The scan could work... walk the upper devices looking for vlans and add/delete filters
>>> based on the protocol of the vlan devices.
>>>
>>> Seems kind of hacky, but let me give this one a try...
>>
>> dev->vlan_info->vid_list might be a more appropriate list since
>> vlan_vid_add() can be called not only by vlan devices.
>
> That's private to vlan implementation and I don't think this is a good reason
> to expose it.
I'm not thinking that scanning directly this list is appropriate.
My point is that vlan layer manages the exact vid list that dev is
required to unfilter and we maybe don't want to manage such lists
redundantly.
We can make APIs to utilize the vid list indirectly.
A simple (but inefficient) way is to make a function like
"bool vlan_has_vid(dev, proto, vid)" and check for all 4094 vids using it.
A possible more efficient way is the one using bitmap. We can make a
function vlan_vids_inuse(dev, proto, bitmap) and get bitmap of vids,
like udp_lib_lport_inuse().
Thanks,
Toshiaki Makita
^ permalink raw reply
* Calltrace in process_backlog()
From: sdrb @ 2014-09-18 9:53 UTC (permalink / raw)
To: netdev
Hello,
I'm writing some network driver for Linux 3.3.8 and I've got problems with
it. I get following calltrace:
[K 3120.810795] Unable to handle kernel paging request at virtual address
00100104
[K 3120.818189] pgd = c0004000
[K 3120.821002] [00100104] *pgd=00000000
[K 3120.824700] Internal error: Oops: 817 [#1]
[K 3120.828919] Modules linked in: (...) ebt_among ebt_802_3 ebtable_nat
[K 3120.913717] CPU: 0 Tainted: G O
(3.3.8 #6)
[K 3120.919190] PC is at process_backlog+0x108/0x148
[K 3120.923938] LR is at __kfree_skb+0x80/0xc8
[K 3120.928168] pc : [<c016a6f8>] lr : [<c01631c4>] psr: 80000093
[K 3120.928179] sp : c0299e70 ip : c0299e00 fp : c0299e94
[K 3120.939946] r10: c02b3974 r9 : c02da548 r8 : 00000000
[K 3120.945313] r7 : c02b3994 r6 : 00000028 r5 : 00000027 r4 : c02b39a0
[K 3120.951994] r3 : 00000000 r2 : 00200200 r1 : 00100100 r0 : 00100100
[K 3120.958676] Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[K 3120.966233] Control: 000039ff Table: 06be8000 DAC: 00000017
[K 3120.972123] Process swapper (pid: 0, stack limit = 0xc0298270)
[K 3120.978104] Stack: (0xc0299e70 to 0xc029a000)
[K 3120.982600] 9e60: c02b39a0
c02b3960 00000001 00000040
[K 3120.990960] 9e80: 0000012c c02b3968 c0299ecc c0299e98 c016c81c
c016a5fc 00000003 00044de2
[K 3120.999323] 9ea0: c02d4880 c02d48b0 c0298000 00000001 00000100
c02d4880 00000009 00000003
[K 3121.007681] 9ec0: c0299f04 c0299ed0 c001a59c c016c7b0 c0299eec
c0299ee0 c004722c 00000005
[K 3121.016044] 9ee0: 00000000 0000001f c0299f74 00004000 69054041
002926a0 c0299f14 c0299f08
[K 3121.024401] 9f00: c001a9bc c001a524 c0299f2c c0299f18 c0009930
c001a980 c0009a8c 60000013
[K 3121.032765] 9f20: c0299f3c c0299f30 c00081d0 c00098d0 c0299f94
c0299f40 c0008c70 c00081cc
[K 3121.041129] 9f40: 00000000 c02aa630 c0299f88 60000013 c0298000
c029d0a4 c02b3ae8 c029d09c
[K 3121.049493] 9f60: 00004000 69054041 002926a0 c0299f94 c0299f98
c0299f88 c0009c30 c0009a8c
[K 3121.057858] 9f80: 60000013 ffffffff c0299fb4 c0299f98 c0009c30
c0009a70 c029c458 c029a0b0
[K 3121.066222] 9fa0: c02b3ab4 c0293f4c c0299fc4 c0299fb8 c01e373c
c0009bd8 c0299ff4 c0299fc8
[K 3121.074585] 9fc0: c027a79c c01e36e8 c027a1a8 00000000 00000000
c0293f4c 00000000 000039fd
[K 3121.082940] 9fe0: c029a034 c0293f48 00000000 c0299ff8 00008040
c027a504 00000000 00000000
[K 3121.091281] Backtrace:
[K 3121.093853] [<c016a5f0>] (process_backlog+0x0/0x148) from [<c016c81c>]
(net_rx_action+0x78/0x190)
[K 3121.102914] [<c016c7a4>] (net_rx_action+0x0/0x190) from [<c001a59c>]
(__do_softirq+0x84/0x11c)
[K 3121.111714] [<c001a518>] (__do_softirq+0x0/0x11c) from [<c001a9bc>]
(irq_exit+0x48/0x54)
[K 3121.119985] [<c001a974>] (irq_exit+0x0/0x54) from [<c0009930>]
(handle_IRQ+0x6c/0x8c)
[K 3121.127997] [<c00098c4>] (handle_IRQ+0x0/0x8c) from [<c00081d0>]
(asm_do_IRQ+0x10/0x14)
[K 3121.136176] r5:60000013 r4:c0009a8c
[K 3121.139894] [<c00081c0>] (asm_do_IRQ+0x0/0x14) from [<c0008c70>]
(__irq_svc+0x30/0xa0)
[K 3121.147977] Exception stack(0xc0299f40 to 0xc0299f88)
[K 3121.153180] 9f40: 00000000 c02aa630 c0299f88 60000013 c0298000
c029d0a4 c02b3ae8 c029d09c
[K 3121.161544] 9f60: 00004000 69054041 002926a0 c0299f94 c0299f98
c0299f88 c0009c30 c0009a8c
[K 3121.169896] 9f80: 60000013 ffffffff
[K 3121.173511] [<c0009a64>] (default_idle+0x0/0x2c) from [<c0009c30>]
(cpu_idle+0x64/0xac)
[K 3121.181697] [<c0009bcc>] (cpu_idle+0x0/0xac) from [<c01e373c>]
(rest_init+0x60/0x78)
[K 3121.189608] r6:c0293f4c r5:c02b3ab4 r4:c029a0b0 r3:c029c458
[K 3121.195449] [<c01e36dc>] (rest_init+0x0/0x78) from [<c027a79c>]
(start_kernel+0x2a4/0x2f8)
[K 3121.203937] [<c027a4f8>] (start_kernel+0x0/0x2f8) from [<00008040>]
(0x8040)
[K 3121.211156] Code: e1530002 2a000007 e8940006 e59f0034 (e5812004)
[K 3121.218336] ---[ end trace 2f3f1c237d8fec1f ]---
[K 3121.223119] Kernel panic - not syncing: Fatal exception in interrupt
[K 3121.229630] Rebooting in 3 seconds..+No devices on IDE controller 0
Hovewer the calltrace occures in kernel - I suspect that this problem relates
somehow to my driver. Unfortunately I cannot find where the problem is.
Symbol with offset "process_backlog+0x108" points to following line:
list_del(&napi->poll_list);
in process_backlog().
I know that the this problem occures because there is napi->poll_list
freed twice. But I cannot find out where in my code is the source
of the problem. How can I find it?
The system bases on single core ARM.
Any suggestions?
^ permalink raw reply
* [PATCHv2 1/1] bluetooth: Check for SCO type before setting retransmission effort
From: Bernhard Thaler @ 2014-09-18 10:15 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg, davem
Cc: linux-bluetooth, netdev, linux-kernel, Bernhard Thaler
In-Reply-To: <8B07B86E-19D4-49E2-B471-DAF31C8D4F34@holtmann.org>
SCO connection cannot be setup to devices that do not support retransmission.
Patch based on http://permalink.gmane.org/gmane.linux.bluez.kernel/7779 and
adapted for this kernel version.
Code changed to check SCO/eSCO type before setting retransmission effort
and max. latency. The purpose of the patch is to support older devices not
capable of eSCO.
Tested on Blackberry 655+ headset which does not support retransmission.
Credits go to Alexander Sommerhuber.
Signed-off-by: Bernhard Thaler <bernhard.thaler@r-it.at>
---
net/bluetooth/hci_conn.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index faff624..f6e3183 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -194,10 +194,18 @@ bool hci_setup_sync(struct hci_conn *conn, __u16 handle)
param = &sco_param_wideband[conn->attempt - 1];
break;
case SCO_AIRMODE_CVSD:
- if (conn->attempt > ARRAY_SIZE(sco_param_cvsd))
- return false;
- cp.retrans_effort = 0x01;
- param = &sco_param_cvsd[conn->attempt - 1];
+ if (!lmp_esco_capable(conn->link)) {
+ /* sco_param_cvsd contains SCO in last two elements */
+ if ((conn->attempt + 3) > ARRAY_SIZE(sco_param_cvsd))
+ return false;
+ cp.retrans_effort = 0xff;
+ param = &sco_param_cvsd[(conn->attempt + 2)];
+ } else {
+ if (conn->attempt > ARRAY_SIZE(sco_param_cvsd))
+ return false;
+ cp.retrans_effort = 0x01;
+ param = &sco_param_cvsd[conn->attempt - 1];
+ }
break;
default:
return false;
--
1.7.10.4
^ permalink raw reply related
* pull-request: can 2014-09-18
From: Marc Kleine-Budde @ 2014-09-18 10:40 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel
this is a pull request of 8 patches for current net.
A patch by Roger Quadros for the c_can driver fixes the swapped parameters of
the c_can_hw_raminit_ti() function. Oliver Hartkopp adds the missing PCI ids to
the peak_pci driver to support the single channel PCAN ExpressCard 34 adapter.
David Dueck converts the at91_can driver to use proper clock handling
functions. Then there are 5 patches by David Jander and me which fix several
mailbox related problems in the flexcan driver.
Marc
---
The following changes since commit 6a38792ca8a5da28f65dc42eeb73d9a431f8d0fd:
scsi: use 'depends' instead of 'select' for SCSI_FC_ATTRS (2014-09-16 16:55:55 -0400)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can.git tags/linux-can-fixes-for-3.17-20140918
for you to fetch changes up to e77980e50bc2850599d4d9c0192b67a9ffd6daac:
can: at91_can: add missing prepare and unprepare of the clock (2014-09-18 11:15:37 +0200)
----------------------------------------------------------------
linux-can-fixes-for-3.17-20140918
----------------------------------------------------------------
David Dueck (1):
can: at91_can: add missing prepare and unprepare of the clock
David Jander (2):
can: flexcan: correctly initialize mailboxes
can: flexcan: implement workaround for errata ERR005829
Marc Kleine-Budde (3):
can: flexcan: mark TX mailbox as TX_INACTIVE
can: flexcan: put TX mailbox into TX_INACTIVE mode after tx-complete
can: flexcan: increase FLEXCAN_MCR_MAXMB() macro to 7 bits
Oliver Hartkopp (1):
can: peak_pci: add PCI ID definition pcie card variant
Roger Quadros (1):
can: c_can_platform: fix parameters of c_can_hw_raminit_ti()
drivers/net/can/at91_can.c | 8 ++++---
drivers/net/can/c_can/c_can_platform.c | 4 ++--
drivers/net/can/flexcan.c | 43 ++++++++++++++++++++++++++++++----
drivers/net/can/sja1000/peak_pci.c | 6 ++++-
4 files changed, 51 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH 2/8] can: peak_pci: add PCI ID definition pcie card variant
From: Marc Kleine-Budde @ 2014-09-18 10:40 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Oliver Hartkopp, Marc Kleine-Budde
In-Reply-To: <1411036862-13255-1-git-send-email-mkl@pengutronix.de>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Add PCI ID definition for the single channel PCAN ExpressCard 34 adapter. Due
to the subsystem id evaluation the correct number of channels (here 1) is
created at initialization time. Tested including the LED functionality.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/sja1000/peak_pci.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/sja1000/peak_pci.c b/drivers/net/can/sja1000/peak_pci.c
index 7a85590..e5fac36 100644
--- a/drivers/net/can/sja1000/peak_pci.c
+++ b/drivers/net/can/sja1000/peak_pci.c
@@ -70,6 +70,8 @@ struct peak_pci_chan {
#define PEAK_PC_104P_DEVICE_ID 0x0006 /* PCAN-PC/104+ cards */
#define PEAK_PCI_104E_DEVICE_ID 0x0007 /* PCAN-PCI/104 Express cards */
#define PEAK_MPCIE_DEVICE_ID 0x0008 /* The miniPCIe slot cards */
+#define PEAK_PCIE_OEM_ID 0x0009 /* PCAN-PCI Express OEM */
+#define PEAK_PCIEC34_DEVICE_ID 0x000A /* PCAN-PCI Express 34 (one channel) */
#define PEAK_PCI_CHAN_MAX 4
@@ -87,6 +89,7 @@ static const struct pci_device_id peak_pci_tbl[] = {
{PEAK_PCI_VENDOR_ID, PEAK_CPCI_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
#ifdef CONFIG_CAN_PEAK_PCIEC
{PEAK_PCI_VENDOR_ID, PEAK_PCIEC_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PEAK_PCIEC34_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
#endif
{0,}
};
@@ -653,7 +656,8 @@ static int peak_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
* This must be done *before* register_sja1000dev() but
* *after* devices linkage
*/
- if (pdev->device == PEAK_PCIEC_DEVICE_ID) {
+ if (pdev->device == PEAK_PCIEC_DEVICE_ID ||
+ pdev->device == PEAK_PCIEC34_DEVICE_ID) {
err = peak_pciec_probe(pdev, dev);
if (err) {
dev_err(&pdev->dev,
--
2.1.0
^ permalink raw reply related
* [PATCH 3/8] can: flexcan: mark TX mailbox as TX_INACTIVE
From: Marc Kleine-Budde @ 2014-09-18 10:40 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Marc Kleine-Budde, linux-stable
In-Reply-To: <1411036862-13255-1-git-send-email-mkl@pengutronix.de>
This patch fixes the initialization of the TX mailbox. It is now correctly
initialized as TX_INACTIVE not RX_EMPTY.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/flexcan.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 630c7bf..76dcbca 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -136,6 +136,17 @@
/* FLEXCAN message buffers */
#define FLEXCAN_MB_CNT_CODE(x) (((x) & 0xf) << 24)
+#define FLEXCAN_MB_CODE_RX_INACTIVE (0x0 << 24)
+#define FLEXCAN_MB_CODE_RX_EMPTY (0x4 << 24)
+#define FLEXCAN_MB_CODE_RX_FULL (0x2 << 24)
+#define FLEXCAN_MB_CODE_RX_OVERRRUN (0x6 << 24)
+#define FLEXCAN_MB_CODE_RX_RANSWER (0xa << 24)
+
+#define FLEXCAN_MB_CODE_TX_INACTIVE (0x8 << 24)
+#define FLEXCAN_MB_CODE_TX_ABORT (0x9 << 24)
+#define FLEXCAN_MB_CODE_TX_DATA (0xc << 24)
+#define FLEXCAN_MB_CODE_TX_TANSWER (0xe << 24)
+
#define FLEXCAN_MB_CNT_SRR BIT(22)
#define FLEXCAN_MB_CNT_IDE BIT(21)
#define FLEXCAN_MB_CNT_RTR BIT(20)
@@ -867,8 +878,8 @@ static int flexcan_chip_start(struct net_device *dev)
netdev_dbg(dev, "%s: writing ctrl=0x%08x", __func__, reg_ctrl);
flexcan_write(reg_ctrl, ®s->ctrl);
- /* Abort any pending TX, mark Mailbox as INACTIVE */
- flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
+ /* mark TX mailbox as INACTIVE */
+ flexcan_write(FLEXCAN_MB_CODE_TX_INACTIVE,
®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
/* acceptance mask/acceptance code (accept everything) */
--
2.1.0
^ permalink raw reply related
* [PATCH 5/8] can: flexcan: implement workaround for errata ERR005829
From: Marc Kleine-Budde @ 2014-09-18 10:40 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, David Jander, linux-stable,
Marc Kleine-Budde
In-Reply-To: <1411036862-13255-1-git-send-email-mkl@pengutronix.de>
From: David Jander <david@protonic.nl>
This patch implements the workaround mentioned in ERR005829:
ERR005829: FlexCAN: FlexCAN does not transmit a message that is enabled to
be transmitted in a specific moment during the arbitration process.
Workaround: The workaround consists of two extra steps after setting up a
message for transmission:
Step 8: Reserve the first valid mailbox as an inactive mailbox (CODE=0b1000).
If RX FIFO is disabled, this mailbox must be message buffer 0. Otherwise, the
first valid mailbox can be found using the "RX FIFO filters" table in the
FlexCAN chapter of the chip reference manual.
Step 9: Write twice INACTIVE code (0b1000) into the first valid mailbox.
Signed-off-by: David Jander <david@protonic.nl>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/flexcan.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index fc076952..54061c4 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -125,7 +125,9 @@
FLEXCAN_ESR_BOFF_INT | FLEXCAN_ESR_ERR_INT)
/* FLEXCAN interrupt flag register (IFLAG) bits */
-#define FLEXCAN_TX_BUF_ID 8
+/* Errata ERR005829 step7: Reserve first valid MB */
+#define FLEXCAN_TX_BUF_RESERVED 8
+#define FLEXCAN_TX_BUF_ID 9
#define FLEXCAN_IFLAG_BUF(x) BIT(x)
#define FLEXCAN_IFLAG_RX_FIFO_OVERFLOW BIT(7)
#define FLEXCAN_IFLAG_RX_FIFO_WARN BIT(6)
@@ -439,6 +441,14 @@ static int flexcan_start_xmit(struct sk_buff *skb, struct net_device *dev)
flexcan_write(can_id, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_id);
flexcan_write(ctrl, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
+ /* Errata ERR005829 step8:
+ * Write twice INACTIVE(0x8) code to first MB.
+ */
+ flexcan_write(FLEXCAN_MB_CODE_TX_INACTIVE,
+ ®s->cantxfg[FLEXCAN_TX_BUF_RESERVED].can_ctrl);
+ flexcan_write(FLEXCAN_MB_CODE_TX_INACTIVE,
+ ®s->cantxfg[FLEXCAN_TX_BUF_RESERVED].can_ctrl);
+
return NETDEV_TX_OK;
}
@@ -885,6 +895,10 @@ static int flexcan_chip_start(struct net_device *dev)
®s->cantxfg[i].can_ctrl);
}
+ /* Errata ERR005829: mark first TX mailbox as INACTIVE */
+ flexcan_write(FLEXCAN_MB_CODE_TX_INACTIVE,
+ ®s->cantxfg[FLEXCAN_TX_BUF_RESERVED].can_ctrl);
+
/* mark TX mailbox as INACTIVE */
flexcan_write(FLEXCAN_MB_CODE_TX_INACTIVE,
®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
--
2.1.0
^ permalink raw reply related
* [PATCH 6/8] can: flexcan: put TX mailbox into TX_INACTIVE mode after tx-complete
From: Marc Kleine-Budde @ 2014-09-18 10:41 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Marc Kleine-Budde, linux-stable
In-Reply-To: <1411036862-13255-1-git-send-email-mkl@pengutronix.de>
After sending a RTR frame the TX mailbox becomes a RX_EMPTY mailbox. To avoid
side effects when the RX-FIFO is full, this patch puts the TX mailbox into
TX_INACTIVE mode in the transmission complete interrupt handler. This, of
course, leaves a race window between the actual completion of the transmission
and the handling of tx-complete interrupt. However this is the best we can do
without busy polling the tx complete interrupt.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/flexcan.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 54061c4..c17ae9e 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -765,6 +765,9 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
stats->tx_bytes += can_get_echo_skb(dev, 0);
stats->tx_packets++;
can_led_event(dev, CAN_LED_EVENT_TX);
+ /* after sending a RTR frame mailbox is in RX mode */
+ flexcan_write(FLEXCAN_MB_CODE_TX_INACTIVE,
+ ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
flexcan_write((1 << FLEXCAN_TX_BUF_ID), ®s->iflag1);
netif_wake_queue(dev);
}
--
2.1.0
^ permalink raw reply related
* [PATCH 8/8] can: at91_can: add missing prepare and unprepare of the clock
From: Marc Kleine-Budde @ 2014-09-18 10:41 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, David Dueck, Anthony Harivel,
linux-stable, Marc Kleine-Budde
In-Reply-To: <1411036862-13255-1-git-send-email-mkl@pengutronix.de>
From: David Dueck <davidcdueck@googlemail.com>
In order to make the driver work with the common clock framework, this patch
converts the clk_enable()/clk_disable() to
clk_prepare_enable()/clk_disable_unprepare(). While there, add the missing
error handling.
Signed-off-by: David Dueck <davidcdueck@googlemail.com>
Signed-off-by: Anthony Harivel <anthony.harivel@emtrion.de>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/at91_can.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
index f07fa89..05e1aa0 100644
--- a/drivers/net/can/at91_can.c
+++ b/drivers/net/can/at91_can.c
@@ -1123,7 +1123,9 @@ static int at91_open(struct net_device *dev)
struct at91_priv *priv = netdev_priv(dev);
int err;
- clk_enable(priv->clk);
+ err = clk_prepare_enable(priv->clk);
+ if (err)
+ return err;
/* check or determine and set bittime */
err = open_candev(dev);
@@ -1149,7 +1151,7 @@ static int at91_open(struct net_device *dev)
out_close:
close_candev(dev);
out:
- clk_disable(priv->clk);
+ clk_disable_unprepare(priv->clk);
return err;
}
@@ -1166,7 +1168,7 @@ static int at91_close(struct net_device *dev)
at91_chip_stop(dev, CAN_STATE_STOPPED);
free_irq(dev->irq, dev);
- clk_disable(priv->clk);
+ clk_disable_unprepare(priv->clk);
close_candev(dev);
--
2.1.0
^ permalink raw reply related
* [PATCH 1/8] can: c_can_platform: fix parameters of c_can_hw_raminit_ti()
From: Marc Kleine-Budde @ 2014-09-18 10:40 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Roger Quadros, linux-stable,
Marc Kleine-Budde
In-Reply-To: <1411036862-13255-1-git-send-email-mkl@pengutronix.de>
From: Roger Quadros <rogerq@ti.com>
Pass the correct 'mask' and 'value' bits to c_can_hw_raminit_wait_ti(). They
seem to have been swapped in the usage instances.
Reported-by: Jay Schroeder <jay.schroeder@garmin.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/c_can/c_can_platform.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index 109cb44..fb279d6 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -97,14 +97,14 @@ static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
ctrl |= CAN_RAMINIT_DONE_MASK(priv->instance);
writel(ctrl, priv->raminit_ctrlreg);
ctrl &= ~CAN_RAMINIT_DONE_MASK(priv->instance);
- c_can_hw_raminit_wait_ti(priv, ctrl, mask);
+ c_can_hw_raminit_wait_ti(priv, mask, ctrl);
if (enable) {
/* Set start bit and wait for the done bit. */
ctrl |= CAN_RAMINIT_START_MASK(priv->instance);
writel(ctrl, priv->raminit_ctrlreg);
ctrl |= CAN_RAMINIT_DONE_MASK(priv->instance);
- c_can_hw_raminit_wait_ti(priv, ctrl, mask);
+ c_can_hw_raminit_wait_ti(priv, mask, ctrl);
}
spin_unlock(&raminit_lock);
}
--
2.1.0
^ permalink raw reply related
* [PATCH 4/8] can: flexcan: correctly initialize mailboxes
From: Marc Kleine-Budde @ 2014-09-18 10:40 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, David Jander, linux-stable,
Marc Kleine-Budde
In-Reply-To: <1411036862-13255-1-git-send-email-mkl@pengutronix.de>
From: David Jander <david@protonic.nl>
Apparently mailboxes may contain random data at startup, causing some of them
being prepared for message reception. This causes overruns being missed or even
confusing the IRQ check for trasmitted messages, increasing the transmit
counter instead of the error counter.
This patch initializes all mailboxes after the FIFO as RX_INACTIVE.
Signed-off-by: David Jander <david@protonic.nl>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/flexcan.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 76dcbca..fc076952 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -812,6 +812,7 @@ static int flexcan_chip_start(struct net_device *dev)
struct flexcan_regs __iomem *regs = priv->base;
int err;
u32 reg_mcr, reg_ctrl;
+ int i;
/* enable module */
err = flexcan_chip_enable(priv);
@@ -878,6 +879,12 @@ static int flexcan_chip_start(struct net_device *dev)
netdev_dbg(dev, "%s: writing ctrl=0x%08x", __func__, reg_ctrl);
flexcan_write(reg_ctrl, ®s->ctrl);
+ /* clear and invalidate all mailboxes first */
+ for (i = FLEXCAN_TX_BUF_ID; i < ARRAY_SIZE(regs->cantxfg); i++) {
+ flexcan_write(FLEXCAN_MB_CODE_RX_INACTIVE,
+ ®s->cantxfg[i].can_ctrl);
+ }
+
/* mark TX mailbox as INACTIVE */
flexcan_write(FLEXCAN_MB_CODE_TX_INACTIVE,
®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
--
2.1.0
^ permalink raw reply related
* [PATCH 7/8] can: flexcan: increase FLEXCAN_MCR_MAXMB() macro to 7 bits
From: Marc Kleine-Budde @ 2014-09-18 10:41 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Marc Kleine-Budde
In-Reply-To: <1411036862-13255-1-git-send-email-mkl@pengutronix.de>
This patch increases the mask in the FLEXCAN_MCR_MAXMB() to 7 bits as in the
newer flexcan cores the MAXMB field is 7 bits wide.
Reported-by: David Jander <david@protonic.nl>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/flexcan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index c17ae9e..6586309 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -62,7 +62,7 @@
#define FLEXCAN_MCR_BCC BIT(16)
#define FLEXCAN_MCR_LPRIO_EN BIT(13)
#define FLEXCAN_MCR_AEN BIT(12)
-#define FLEXCAN_MCR_MAXMB(x) ((x) & 0x1f)
+#define FLEXCAN_MCR_MAXMB(x) ((x) & 0x7f)
#define FLEXCAN_MCR_IDAM_A (0 << 8)
#define FLEXCAN_MCR_IDAM_B (1 << 8)
#define FLEXCAN_MCR_IDAM_C (2 << 8)
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net v2] bonding: fix div by zero while enslaving and transmitting
From: Ding Tianhong @ 2014-09-18 10:59 UTC (permalink / raw)
To: Nikolay Aleksandrov, netdev
Cc: Eric Dumazet, Andy Gospodarek, Jay Vosburgh, Veaceslav Falico
In-Reply-To: <54196BA3.4020505@redhat.com>
On 2014/9/17 19:08, Nikolay Aleksandrov wrote:
> On 17/09/14 08:15, Ding Tianhong wrote:
>> On 2014/9/12 23:38, Nikolay Aleksandrov wrote:
>>> The problem is that the slave is first linked and slave_cnt is
>>> incremented afterwards leading to a div by zero in the modes that use it
>>> as a modulus. What happens is that in bond_start_xmit()
>>> bond_has_slaves() is used to evaluate further transmission and it becomes
>>> true after the slave is linked in, but when slave_cnt is used in the xmit
>>> path it is still 0, so fetch it once and transmit based on that. Since
>>> it is used only in round-robin and XOR modes, the fix is only for them.
>>> Thanks to Eric Dumazet for pointing out the fault in my first try to fix
>>> this.
>>>
>>
>> Hi, I think no need to add more checks in the xmit fast path, why not add a barrier to make
>> sure the slave_cnt inc to 1 before access it.
>>
>> + /* Increment slave_cnt before linking in the slave so we won't end up in
>> + * bond_start_xmit with bond_has_slaves() true and slave_cnt == 0.
>> + */
>> + bond->slave_cnt++;
>> + wmb();
>>
>> I think it looks more efficiency, sorry for reply so late.
>>
>> Regards
>> Ding
>>
>>
>
> Hi Ding,
> You should re-read Eric's comment to my first fix. In my first attempt I moved the increment before the slave linking which does rcu_assign_pointer() which implies a full memory barrier, IIRC. The issue is that this fixes the writer side and makes sure the increment is visible before linking the slave, but I missed that on the reader side (bond_start_xmit()) we don't have any barriers, so the CPU is free to do whatever it likes with the access to slave_cnt F.e. it can fetch it before the slave list.
> Now, this fix shouldn't be felt much performance-wise since the likely() hint will be correct 99% of the time because the situation where slave_cnt is not in sync is only in a very short period of time while enslaving and releasing slaves. If you'd like to further remove this one check - you could. You can fetch slave_cnt only once in bond_start_xmit() and use that as a check for further transmitting instead of empty slave list but you must pass down the fetched value to the xmitting functions, that is you should not re-fetch it, so it'd probably require you to add additional parameter to all modes' xmit functions so you can pass it down from bond_start_xmit(). Since only 2 modes actually use slave_cnt I don't think that is necessary.
> In any case net should be merged with net-next first.
>
> Cheers,
> Nik
>
Hi Nik:
Thanks for your explanation, I got it, I need to think more about it, thanks.
Ding
>
>
> .
>
^ permalink raw reply
* Re: [net-next PATCH 2/2] net: sched: cls_u32 changes to knode must appear atomic to readers
From: Jamal Hadi Salim @ 2014-09-18 11:38 UTC (permalink / raw)
To: John Fastabend, xiyou.wangcong, davem, eric.dumazet; +Cc: netdev
In-Reply-To: <20140917191202.20529.87231.stgit@nitbit.x32>
On 09/17/14 15:12, John Fastabend wrote:
> Changes to the cls_u32 classifier must appear atomic to the
> readers. Before this patch if a change is requested for both
> the exts and ifindex, first the ifindex is updated then the
> exts with tcf_exts_change(). This opens a small window where
> a reader can have a exts chain with an incorrect ifindex. This
> violates the the RCU semantics.
>
> Here we resolve this by always passing u32_set_parms() a copy
> of the tc_u_knode to work on and then inserting it into the hash
> table after the updates have been successfully applied.
>
> Tested with the following short script:
>
>
> #tc filter add dev p3p2 parent 8001:0 protocol ip prio 99 handle 1: \
> u32 divisor 256
>
> #tc filter add dev p3p2 parent 8001:0 protocol ip prio 99 \
> u32 link 1: hashkey mask ffffff00 at 12 \
> match ip src 192.168.8.0/2
>
> #tc filter add dev p3p2 parent 8001:0 protocol ip prio 102 \
> handle 1::10 u32 classid 1:2 ht 1: \
> match ip src 192.168.8.0/8 match ip tos 0x0a 1e
>
> #tc filter change dev p3p2 parent 8001:0 protocol ip prio 102 \
> handle 1::10 u32 classid 1:2 ht 1: \
> match ip src 1.1.0.0/8 match ip tos 0x0b 1e
>
> CC: Eric Dumazet <edumazet@google.com>
> CC: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Looks good to me.
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* [net-next 00/11][pull request] Intel Wired LAN Driver Updates 2014-09-18
From: Jeff Kirsher @ 2014-09-18 12:26 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains updates to ixgbe and ixgbevf.
Ethan Zhao cleans up ixgbe and ixgbevf by removing bd_number from the
adapter struct because it is not longer useful.
Mark fixes ixgbe where if a hardware transmit timestamp is requested,
an uninitialized workqueue entry may be scheduled. Added a check for
a PTP clock to avoid that.
Jacob provides a number of cleanups for ixgbe. Since we may call
ixgbe_acquire_msix_vectors() prior to registering our netdevice, we
should not use the netdevice specific printk and use e_dev_warn()
instead. Similar to how ixgbevf handles acquiring MSI-X vectors, we
can return an error code instead of relying on the flag being set.
This makes it more clear that we have failed to setup MSI-X mode and
will make it easier to consolidate MSI-X related code into a single
function. In the case of disabling DCB, it is not an error since we
still can function, we just have to let the user know. So use
e_dev_warn() instead of e_err(). Added warnings for other features
that are disabled when we are without MSI-X support. Cleanup flags
that are no longer used or needed.
The following are changes since commit bf3c228d36c6b3c90074f928e84e318621969cc6:
net: fec: fix build error at m68k platform
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Ethan Zhao (2):
ixgbevf: remove useless bd_number from struct ixgbevf_adapter
ixgbe: remove useless bd_number from adapter struct
Jacob Keller (8):
ixgbe: use e_dev_warn instead of netif_printk
ixgbe: return integer from ixgbe_acquire_msix_vectors
ixgbe: move msix_entries allocation into ixgbe_acquire_msix_vectors
ixgbe: determine vector count inside ixgbe_acquire_msix_vectors
ixgbe: use e_dev_warn instead of e_err for displaying warning
ixgbe: use e_dev_warn instead of netif_printk
ixgbe: add warnings for other disabled features without MSI-X support
ixgbe: remove IXGBE_FLAG_MSI(X)_CAPABLE flags
Mark Rustad (1):
ixgbe: Do not schedule an uninitialized workqueue entry
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 4 -
drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 151 +++++++++++-----------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +-
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 1 -
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 4 -
5 files changed, 83 insertions(+), 88 deletions(-)
--
1.9.3
^ permalink raw reply
* [net-next 01/11] ixgbevf: remove useless bd_number from struct ixgbevf_adapter
From: Jeff Kirsher @ 2014-09-18 12:26 UTC (permalink / raw)
To: davem; +Cc: Ethan Zhao, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1411043221-7163-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Ethan Zhao <ethan.zhao@oracle.com>
It is useless and buggy, just remove it.
Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 1 -
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 4 ----
2 files changed, 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
index a0a1de9..ba96cb5 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
@@ -385,7 +385,6 @@ struct ixgbevf_adapter {
/* structs defined in ixgbe_vf.h */
struct ixgbe_hw hw;
u16 msg_enable;
- u16 bd_number;
/* Interrupt Throttle Rate */
u32 eitr_param;
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index c22a00c..030a219 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -3464,7 +3464,6 @@ static int ixgbevf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
struct ixgbevf_adapter *adapter = NULL;
struct ixgbe_hw *hw = NULL;
const struct ixgbevf_info *ii = ixgbevf_info_tbl[ent->driver_data];
- static int cards_found;
int err, pci_using_dac;
err = pci_enable_device(pdev);
@@ -3525,8 +3524,6 @@ static int ixgbevf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
ixgbevf_assign_netdev_ops(netdev);
- adapter->bd_number = cards_found;
-
/* Setup hw api */
memcpy(&hw->mac.ops, ii->mac_ops, sizeof(hw->mac.ops));
hw->mac.type = ii->mac;
@@ -3601,7 +3598,6 @@ static int ixgbevf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
hw_dbg(hw, "MAC: %d\n", hw->mac.type);
hw_dbg(hw, "Intel(R) 82599 Virtual Function\n");
- cards_found++;
return 0;
err_register:
--
1.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox