* [PATCH net-next v1 1/5] ixgbe: Add a RETA query command to VF-PF channel API
From: Vlad Zolotarov @ 2014-12-31 9:51 UTC (permalink / raw)
To: netdev; +Cc: gleb, avi, jeffrey.t.kirsher, Vlad Zolotarov
In-Reply-To: <1420019519-18139-1-git-send-email-vladz@cloudius-systems.com>
82599 VFs and PF share the same RSS redirection table (RETA). Therefore we
just return it for all VFs.
RETA table is an array of 32 registers and the maximum number of registers
that may be delivered in a single VF-PF channel command is 15. Therefore
we will deliver the whole table in 3 steps: 12, 12 and 8 registers in each
step correspondingly. Thus this patch does the following:
- Adds a new API version (to specify a new commands set).
- Adds the IXGBE_VF_GET_RETA_[0,1,2] commands to the VF-PF commands set.
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
---
New in v1 (compared to RFC):
- Use "if-else" statement instead of a "switch-case" for a single option case
(in ixgbe_get_vf_reta()).
---
drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 6 +++++
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 31 ++++++++++++++++++++++++++
2 files changed, 37 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
index a5cb755..c1123d9 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
@@ -73,6 +73,7 @@ enum ixgbe_pfvf_api_rev {
ixgbe_mbox_api_10, /* API version 1.0, linux/freebsd VF driver */
ixgbe_mbox_api_20, /* API version 2.0, solaris Phase1 VF driver */
ixgbe_mbox_api_11, /* API version 1.1, linux/freebsd VF driver */
+ ixgbe_mbox_api_12, /* API version 1.2, linux/freebsd VF driver */
/* This value should always be last */
ixgbe_mbox_api_unknown, /* indicates that API version is not known */
};
@@ -91,6 +92,11 @@ enum ixgbe_pfvf_api_rev {
/* mailbox API, version 1.1 VF requests */
#define IXGBE_VF_GET_QUEUES 0x09 /* get queue configuration */
+/* mailbox API, version 1.2 VF requests */
+#define IXGBE_VF_GET_RETA_0 0x0a /* get RETA[0..11] */
+#define IXGBE_VF_GET_RETA_1 0x0b /* get RETA[12..23] */
+#define IXGBE_VF_GET_RETA_2 0x0c /* get RETA[24..31] */
+
/* GET_QUEUES return data indices within the mailbox */
#define IXGBE_VF_TX_QUEUES 1 /* number of Tx queues supported */
#define IXGBE_VF_RX_QUEUES 2 /* number of Rx queues supported */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index c76ba90..b1625c8 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -427,6 +427,7 @@ static s32 ixgbe_set_vf_lpe(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
#endif /* CONFIG_FCOE */
switch (adapter->vfinfo[vf].vf_api) {
case ixgbe_mbox_api_11:
+ case ixgbe_mbox_api_12:
/*
* Version 1.1 supports jumbo frames on VFs if PF has
* jumbo frames enabled which means legacy VFs are
@@ -894,6 +895,7 @@ static int ixgbe_negotiate_vf_api(struct ixgbe_adapter *adapter,
switch (api) {
case ixgbe_mbox_api_10:
case ixgbe_mbox_api_11:
+ case ixgbe_mbox_api_12:
adapter->vfinfo[vf].vf_api = api;
return 0;
default:
@@ -917,6 +919,7 @@ static int ixgbe_get_vf_queues(struct ixgbe_adapter *adapter,
switch (adapter->vfinfo[vf].vf_api) {
case ixgbe_mbox_api_20:
case ixgbe_mbox_api_11:
+ case ixgbe_mbox_api_12:
break;
default:
return -1;
@@ -944,6 +947,25 @@ static int ixgbe_get_vf_queues(struct ixgbe_adapter *adapter,
return 0;
}
+static int ixgbe_get_vf_reta(struct ixgbe_adapter *adapter,
+ u32 *msgbuf, u32 vf, int reta_offset_dw,
+ size_t dwords)
+{
+ struct ixgbe_hw *hw = &adapter->hw;
+ int i;
+ u32 *reta = &msgbuf[1];
+
+ /* verify the PF is supporting the correct API */
+ if (adapter->vfinfo[vf].vf_api != ixgbe_mbox_api_12)
+ return -EPERM;
+
+ /* Read the appropriate portion of RETA */
+ for (i = 0; i < dwords; i++)
+ reta[i] = IXGBE_READ_REG(hw, IXGBE_RETA(i + reta_offset_dw));
+
+ return 0;
+}
+
static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
{
u32 mbx_size = IXGBE_VFMAILBOX_SIZE;
@@ -1000,6 +1022,15 @@ static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
case IXGBE_VF_GET_QUEUES:
retval = ixgbe_get_vf_queues(adapter, msgbuf, vf);
break;
+ case IXGBE_VF_GET_RETA_0:
+ retval = ixgbe_get_vf_reta(adapter, msgbuf, vf, 0, 12);
+ break;
+ case IXGBE_VF_GET_RETA_1:
+ retval = ixgbe_get_vf_reta(adapter, msgbuf, vf, 12, 12);
+ break;
+ case IXGBE_VF_GET_RETA_2:
+ retval = ixgbe_get_vf_reta(adapter, msgbuf, vf, 24, 8);
+ break;
default:
e_err(drv, "Unhandled Msg %8.8x\n", msgbuf[0]);
retval = IXGBE_ERR_MBX;
--
2.1.0
^ permalink raw reply related
* [PATCH net-next v1 2/5] ixgbevf: Add a RETA query code
From: Vlad Zolotarov @ 2014-12-31 9:51 UTC (permalink / raw)
To: netdev; +Cc: gleb, avi, jeffrey.t.kirsher, Vlad Zolotarov
In-Reply-To: <1420019519-18139-1-git-send-email-vladz@cloudius-systems.com>
- Added a new API version support.
- Added the query implementation in the ixgbevf.
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
---
New in v1 (compared to RFC):
- Use "if-else" statement instead of a "switch-case" for a single option case
(in ixgbevf_get_reta()).
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 4 +-
drivers/net/ethernet/intel/ixgbevf/mbx.h | 6 ++
drivers/net/ethernet/intel/ixgbevf/vf.c | 73 +++++++++++++++++++++++
drivers/net/ethernet/intel/ixgbevf/vf.h | 1 +
4 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 62a0d8e..ba6ab61 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -1880,7 +1880,8 @@ static void ixgbevf_init_last_counter_stats(struct ixgbevf_adapter *adapter)
static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
{
struct ixgbe_hw *hw = &adapter->hw;
- int api[] = { ixgbe_mbox_api_11,
+ int api[] = { ixgbe_mbox_api_12,
+ ixgbe_mbox_api_11,
ixgbe_mbox_api_10,
ixgbe_mbox_api_unknown };
int err = 0, idx = 0;
@@ -3525,6 +3526,7 @@ static int ixgbevf_change_mtu(struct net_device *netdev, int new_mtu)
switch (adapter->hw.api_version) {
case ixgbe_mbox_api_11:
+ case ixgbe_mbox_api_12:
max_possible_frame = IXGBE_MAX_JUMBO_FRAME_SIZE;
break;
default:
diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.h b/drivers/net/ethernet/intel/ixgbevf/mbx.h
index 0bc3005..3e148a8 100644
--- a/drivers/net/ethernet/intel/ixgbevf/mbx.h
+++ b/drivers/net/ethernet/intel/ixgbevf/mbx.h
@@ -86,6 +86,7 @@ enum ixgbe_pfvf_api_rev {
ixgbe_mbox_api_10, /* API version 1.0, linux/freebsd VF driver */
ixgbe_mbox_api_20, /* API version 2.0, solaris Phase1 VF driver */
ixgbe_mbox_api_11, /* API version 1.1, linux/freebsd VF driver */
+ ixgbe_mbox_api_12, /* API version 1.2, linux/freebsd VF driver */
/* This value should always be last */
ixgbe_mbox_api_unknown, /* indicates that API version is not known */
};
@@ -104,6 +105,11 @@ enum ixgbe_pfvf_api_rev {
/* mailbox API, version 1.1 VF requests */
#define IXGBE_VF_GET_QUEUE 0x09 /* get queue configuration */
+/* mailbox API, version 1.2 VF requests */
+#define IXGBE_VF_GET_RETA_0 0x0a /* get RETA[0..11] */
+#define IXGBE_VF_GET_RETA_1 0x0b /* get RETA[12..23] */
+#define IXGBE_VF_GET_RETA_2 0x0c /* get RETA[24..31] */
+
/* GET_QUEUES return data indices within the mailbox */
#define IXGBE_VF_TX_QUEUES 1 /* number of Tx queues supported */
#define IXGBE_VF_RX_QUEUES 2 /* number of Rx queues supported */
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index cdb53be..8b98cdf 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -258,6 +258,78 @@ static s32 ixgbevf_set_uc_addr_vf(struct ixgbe_hw *hw, u32 index, u8 *addr)
return ret_val;
}
+static inline int _ixgbevf_get_reta(struct ixgbe_hw *hw, u32 *msgbuf,
+ u32 *reta, u32 op, int reta_offset_dw,
+ size_t dwords)
+{
+ int err;
+
+ msgbuf[0] = op;
+ err = hw->mbx.ops.write_posted(hw, msgbuf, 1);
+
+ if (err)
+ return err;
+
+ err = hw->mbx.ops.read_posted(hw, msgbuf, 1 + dwords);
+
+ if (err)
+ return err;
+
+ msgbuf[0] &= ~IXGBE_VT_MSGTYPE_CTS;
+
+ /* If we didn't get an ACK there must have been
+ * some sort of mailbox error so we should treat it
+ * as such.
+ */
+ if (msgbuf[0] != (op | IXGBE_VT_MSGTYPE_ACK))
+ return IXGBE_ERR_MBX;
+
+ memcpy(reta + reta_offset_dw, msgbuf + 1, 4 * dwords);
+
+ return 0;
+}
+
+/**
+ * ixgbevf_get_reta - get the RSS redirection table (RETA) contents.
+ * @hw: pointer to the HW structure
+ * @reta: buffer to fill with RETA contents.
+ *
+ * The "reta" buffer should be big enough to contain 32 registers.
+ *
+ * Returns: 0 on success.
+ * if API doesn't support this operation - (-EPERM).
+ */
+int ixgbevf_get_reta(struct ixgbe_hw *hw, u32 *reta)
+{
+ int err;
+ u32 msgbuf[IXGBE_VFMAILBOX_SIZE];
+
+ /* Return an error if API doesn't RETA querying. */
+ if (hw->api_version != ixgbe_mbox_api_12)
+ return -EPERM;
+
+ /* Fetch RETA from the PF. We do it in 3 steps due to mailbox size
+ * limitation - we can bring up to 15 dwords every time while RETA
+ * consists of 32 dwords. Therefore we'll bring 12, 12 and 8 dwords in
+ * each step correspondingly.
+ */
+
+ /* RETA[0..11] */
+ err = _ixgbevf_get_reta(hw, msgbuf, reta, IXGBE_VF_GET_RETA_0, 0, 12);
+ if (err)
+ return err;
+
+ /* RETA[12..23] */
+ err = _ixgbevf_get_reta(hw, msgbuf, reta, IXGBE_VF_GET_RETA_1, 12, 12);
+ if (err)
+ return err;
+
+ /* RETA[24..31] */
+ err = _ixgbevf_get_reta(hw, msgbuf, reta, IXGBE_VF_GET_RETA_2, 24, 8);
+
+ return err;
+}
+
/**
* ixgbevf_set_rar_vf - set device MAC address
* @hw: pointer to hardware structure
@@ -545,6 +617,7 @@ int ixgbevf_get_queues(struct ixgbe_hw *hw, unsigned int *num_tcs,
/* do nothing if API doesn't support ixgbevf_get_queues */
switch (hw->api_version) {
case ixgbe_mbox_api_11:
+ case ixgbe_mbox_api_12:
break;
default:
return 0;
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.h b/drivers/net/ethernet/intel/ixgbevf/vf.h
index 5b17242..73c1b33 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.h
@@ -208,5 +208,6 @@ void ixgbevf_rlpml_set_vf(struct ixgbe_hw *hw, u16 max_size);
int ixgbevf_negotiate_api_version(struct ixgbe_hw *hw, int api);
int ixgbevf_get_queues(struct ixgbe_hw *hw, unsigned int *num_tcs,
unsigned int *default_tc);
+int ixgbevf_get_reta(struct ixgbe_hw *hw, u32 *reta);
#endif /* __IXGBE_VF_H__ */
--
2.1.0
^ permalink raw reply related
* [PATCH net-next v1 3/5] ixgbe: Add GET_RSS_KEY command to VF-PF channel commands set
From: Vlad Zolotarov @ 2014-12-31 9:51 UTC (permalink / raw)
To: netdev; +Cc: gleb, avi, jeffrey.t.kirsher, Vlad Zolotarov
In-Reply-To: <1420019519-18139-1-git-send-email-vladz@cloudius-systems.com>
82599 VFs and PF share the same RSS Key. Therefore we will return
the same RSS key for all VFs.
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
---
New in v1 (compared to RFC):
- Use "if-else" statement instead of a "switch-case" for a single option case
(in ixgbe_get_vf_rss_key()).
---
drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 2 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 21 +++++++++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
index c1123d9..52e775b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
@@ -97,6 +97,8 @@ enum ixgbe_pfvf_api_rev {
#define IXGBE_VF_GET_RETA_1 0x0b /* get RETA[12..23] */
#define IXGBE_VF_GET_RETA_2 0x0c /* get RETA[24..31] */
+#define IXGBE_VF_GET_RSS_KEY 0x0d /* get RSS key */
+
/* GET_QUEUES return data indices within the mailbox */
#define IXGBE_VF_TX_QUEUES 1 /* number of Tx queues supported */
#define IXGBE_VF_RX_QUEUES 2 /* number of Rx queues supported */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index b1625c8..d79415e 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -966,6 +966,24 @@ static int ixgbe_get_vf_reta(struct ixgbe_adapter *adapter,
return 0;
}
+static int ixgbe_get_vf_rss_key(struct ixgbe_adapter *adapter,
+ u32 *msgbuf, u32 vf)
+{
+ struct ixgbe_hw *hw = &adapter->hw;
+ int i;
+ u32 *rss_key = &msgbuf[1];
+
+ /* verify the PF is supporting the correct API */
+ if (adapter->vfinfo[vf].vf_api != ixgbe_mbox_api_12)
+ return -EPERM;
+
+ /* Read the RSS KEY */
+ for (i = 0; i < 10; i++)
+ rss_key[i] = IXGBE_READ_REG(hw, IXGBE_RSSRK(i));
+
+ return 0;
+}
+
static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
{
u32 mbx_size = IXGBE_VFMAILBOX_SIZE;
@@ -1031,6 +1049,9 @@ static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
case IXGBE_VF_GET_RETA_2:
retval = ixgbe_get_vf_reta(adapter, msgbuf, vf, 24, 8);
break;
+ case IXGBE_VF_GET_RSS_KEY:
+ retval = ixgbe_get_vf_rss_key(adapter, msgbuf, vf);
+ break;
default:
e_err(drv, "Unhandled Msg %8.8x\n", msgbuf[0]);
retval = IXGBE_ERR_MBX;
--
2.1.0
^ permalink raw reply related
* [PATCH net-next v1 4/5] ixgbevf: Add RSS Key query code
From: Vlad Zolotarov @ 2014-12-31 9:51 UTC (permalink / raw)
To: netdev; +Cc: gleb, avi, jeffrey.t.kirsher, Vlad Zolotarov
In-Reply-To: <1420019519-18139-1-git-send-email-vladz@cloudius-systems.com>
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
---
New in v1 (compared to RFC):
- Use "if-else" statement instead of a "switch-case" for a single option case
(in ixgbevf_get_rss_key()).
---
drivers/net/ethernet/intel/ixgbevf/mbx.h | 2 ++
drivers/net/ethernet/intel/ixgbevf/vf.c | 44 ++++++++++++++++++++++++++++++++
drivers/net/ethernet/intel/ixgbevf/vf.h | 1 +
3 files changed, 47 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.h b/drivers/net/ethernet/intel/ixgbevf/mbx.h
index 3e148a8..9674ac8 100644
--- a/drivers/net/ethernet/intel/ixgbevf/mbx.h
+++ b/drivers/net/ethernet/intel/ixgbevf/mbx.h
@@ -110,6 +110,8 @@ enum ixgbe_pfvf_api_rev {
#define IXGBE_VF_GET_RETA_1 0x0b /* get RETA[12..23] */
#define IXGBE_VF_GET_RETA_2 0x0c /* get RETA[24..31] */
+#define IXGBE_VF_GET_RSS_KEY 0x0d /* get RSS hash key */
+
/* GET_QUEUES return data indices within the mailbox */
#define IXGBE_VF_TX_QUEUES 1 /* number of Tx queues supported */
#define IXGBE_VF_RX_QUEUES 2 /* number of Rx queues supported */
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index 8b98cdf..dbac264 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -290,6 +290,50 @@ static inline int _ixgbevf_get_reta(struct ixgbe_hw *hw, u32 *msgbuf,
}
/**
+ * ixgbevf_get_rss_key - get the RSS Random Key
+ * @hw: pointer to the HW structure
+ * @reta: buffer to fill with RETA contents.
+ *
+ * The "rss_key" buffer should be big enough to contain 10 registers.
+ *
+ * Returns: 0 on success.
+ * if API doesn't support this operation - (-EPERM).
+ */
+int ixgbevf_get_rss_key(struct ixgbe_hw *hw, u8 *rss_key)
+{
+ int err;
+ u32 msgbuf[IXGBE_VFMAILBOX_SIZE];
+
+ /* Return and error if API doesn't support RSS Random Key retrieval */
+ if (hw->api_version != ixgbe_mbox_api_12)
+ return -EPERM;
+
+ msgbuf[0] = IXGBE_VF_GET_RSS_KEY;
+ err = hw->mbx.ops.write_posted(hw, msgbuf, 1);
+
+ if (err)
+ return err;
+
+ err = hw->mbx.ops.read_posted(hw, msgbuf, 11);
+
+ if (err)
+ return err;
+
+ msgbuf[0] &= ~IXGBE_VT_MSGTYPE_CTS;
+
+ /* If we didn't get an ACK there must have been
+ * some sort of mailbox error so we should treat it
+ * as such.
+ */
+ if (msgbuf[0] != (IXGBE_VF_GET_RSS_KEY | IXGBE_VT_MSGTYPE_ACK))
+ return IXGBE_ERR_MBX;
+
+ memcpy(rss_key, msgbuf + 1, 40);
+
+ return 0;
+}
+
+/**
* ixgbevf_get_reta - get the RSS redirection table (RETA) contents.
* @hw: pointer to the HW structure
* @reta: buffer to fill with RETA contents.
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.h b/drivers/net/ethernet/intel/ixgbevf/vf.h
index 73c1b33..54f53f2b8 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.h
@@ -209,5 +209,6 @@ int ixgbevf_negotiate_api_version(struct ixgbe_hw *hw, int api);
int ixgbevf_get_queues(struct ixgbe_hw *hw, unsigned int *num_tcs,
unsigned int *default_tc);
int ixgbevf_get_reta(struct ixgbe_hw *hw, u32 *reta);
+int ixgbevf_get_rss_key(struct ixgbe_hw *hw, u8 *rss_key);
#endif /* __IXGBE_VF_H__ */
--
2.1.0
^ permalink raw reply related
* [PATCH net-next v1 5/5] ixgbevf: Add the appropriate ethtool ops to query RSS indirection table and key
From: Vlad Zolotarov @ 2014-12-31 9:51 UTC (permalink / raw)
To: netdev; +Cc: gleb, avi, jeffrey.t.kirsher, Vlad Zolotarov
In-Reply-To: <1420019519-18139-1-git-send-email-vladz@cloudius-systems.com>
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
---
drivers/net/ethernet/intel/ixgbevf/ethtool.c | 37 ++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ethtool.c b/drivers/net/ethernet/intel/ixgbevf/ethtool.c
index cc0e5b7..255bbc8 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ethtool.c
@@ -792,6 +792,40 @@ static int ixgbevf_set_coalesce(struct net_device *netdev,
return 0;
}
+static u32 ixgbevf_get_rxfh_indir_size(struct net_device *netdev)
+{
+ return 128;
+}
+
+static u32 ixgbevf_get_rxfh_key_size(struct net_device *netdev)
+{
+ return 40;
+}
+
+static int ixgbevf_get_rxfh(struct net_device *netdev, u32 *indir, u8 *key,
+ u8 *hfunc)
+{
+ struct ixgbevf_adapter *adapter = netdev_priv(netdev);
+ int err;
+
+ if (hfunc)
+ *hfunc = ETH_RSS_HASH_TOP;
+
+ if (indir) {
+ err = ixgbevf_get_reta(&adapter->hw, indir);
+ if (err)
+ return err;
+ }
+
+ if (key) {
+ err = ixgbevf_get_rss_key(&adapter->hw, key);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
static const struct ethtool_ops ixgbevf_ethtool_ops = {
.get_settings = ixgbevf_get_settings,
.get_drvinfo = ixgbevf_get_drvinfo,
@@ -809,6 +843,9 @@ static const struct ethtool_ops ixgbevf_ethtool_ops = {
.get_ethtool_stats = ixgbevf_get_ethtool_stats,
.get_coalesce = ixgbevf_get_coalesce,
.set_coalesce = ixgbevf_set_coalesce,
+ .get_rxfh_indir_size = ixgbevf_get_rxfh_indir_size,
+ .get_rxfh_key_size = ixgbevf_get_rxfh_key_size,
+ .get_rxfh = ixgbevf_get_rxfh,
};
void ixgbevf_set_ethtool_ops(struct net_device *netdev)
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
From: Arend van Spriel @ 2014-12-31 9:56 UTC (permalink / raw)
To: Fu, Zhonghui
Cc: brudley, Franky Lin, meuleman, kvalo, linville, pieterpg,
hdegoede, wens, linux-wireless, brcm80211-dev-list, netdev,
linux-kernel
In-Reply-To: <54A3B1B4.7090705@linux.intel.com>
On 12/31/14 09:20, Fu, Zhonghui wrote:
> From e34419970a07bfcd365f9c66bdfa552188a0cd26 Mon Sep 17 00:00:00 2001
> From: Zhonghui Fu<zhonghui.fu@linux.intel.com>
> Date: Mon, 29 Dec 2014 21:25:31 +0800
> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
>
> WiFi chip has 2 SDIO functions, and PM core will trigger
> twice suspend/resume operations for one WiFi chip to do
> the same things. This patch avoid this case.
We have a patch queued up for this as well, but this one looks good
enough although I personally prefer container_of() instead of
dev_to_sdio_func().
Acked-by: Arend van Spriel <arend@broadcom.com>
> Signed-off-by: Zhonghui Fu<zhonghui.fu@linux.intel.com>
> ---
> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 19 +++++++++++++++++--
> 1 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
> index 3c06e93..eee7818 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
> @@ -1139,11 +1139,18 @@ void brcmf_sdio_wowl_config(struct device *dev, bool enabled)
> static int brcmf_ops_sdio_suspend(struct device *dev)
> {
> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
> + struct brcmf_sdio_dev *sdiodev;
> mmc_pm_flag_t sdio_flags;
> + struct sdio_func *func = dev_to_sdio_func(dev);
>
> brcmf_dbg(SDIO, "Enter\n");
>
> + if (func->num == 2) {
> + return 0;
> + }
> +
> + sdiodev = bus_if->bus_priv.sdio;
> +
> atomic_set(&sdiodev->suspend, true);
>
> if (sdiodev->wowl_enabled) {
> @@ -1164,9 +1171,17 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
> static int brcmf_ops_sdio_resume(struct device *dev)
> {
> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
> + struct brcmf_sdio_dev *sdiodev;
> + struct sdio_func *func = dev_to_sdio_func(dev);
>
> brcmf_dbg(SDIO, "Enter\n");
> +
> + if (func->num == 2) {
> + return 0;
> + }
> +
> + sdiodev = bus_if->bus_priv.sdio;
> +
> if (sdiodev->pdata->oob_irq_supported)
> disable_irq_wake(sdiodev->pdata->oob_irq_nr);
> brcmf_sdio_wd_timer(sdiodev->bus, BRCMF_WD_POLL_MS);
> -- 1.7.1
>
^ permalink raw reply
* Re: [PATCH] wait_for_completion_timeout does not return < 0
From: Sudip Mukherjee @ 2014-12-31 10:31 UTC (permalink / raw)
To: Nicholas Mc Guire; +Cc: Inaky Perez-Gonzalez, linux-wimax, netdev, linux-kernel
In-Reply-To: <1420016643-19707-1-git-send-email-der.herr@hofr.at>
On Wed, Dec 31, 2014 at 04:04:03AM -0500, Nicholas Mc Guire wrote:
> This is only removing the comment which is misleading as
> wait_for_completion_timeout does not return < 0 thus there
> never is anything to be passed on.
a small doubt -
i am seeing that:
unsigned long wait_for_completion_timeout() is calling
long wait_for_common() which is again calling
long __wait_for_common which is again calling
long do_wait_for_common()
now the return value from do_wait_for_common can be -ERESTARTSYS,
so then what happens when wait_for_completion_timeout return this -ERESTARTSYS as an unsigned value ?
it becomes a positive value, and ultimately ctx.result (which is 0) is returned.
so then are we just ignoring the error value from do_wait_for_common() ?
sudip
>
> patch is against linux-next 3.19.0-rc1 -next-20141226
>
> Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
> ---
> drivers/net/wimax/i2400m/driver.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/wimax/i2400m/driver.c b/drivers/net/wimax/i2400m/driver.c
> index 9c78090..0a6384e 100644
> --- a/drivers/net/wimax/i2400m/driver.c
> +++ b/drivers/net/wimax/i2400m/driver.c
> @@ -197,7 +197,6 @@ int i2400m_op_reset(struct wimax_dev *wimax_dev)
> result = -ETIMEDOUT;
> else if (result > 0)
> result = ctx.result;
> - /* if result < 0, pass it on */
> mutex_lock(&i2400m->init_mutex);
> i2400m->reset_ctx = NULL;
> mutex_unlock(&i2400m->init_mutex);
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] wait_for_completion_timeout does not return < 0
From: Nicholas Mc Guire @ 2014-12-31 10:37 UTC (permalink / raw)
To: Sudip Mukherjee; +Cc: Inaky Perez-Gonzalez, linux-wimax, netdev, linux-kernel
In-Reply-To: <20141231103157.GA20842@sudip-PC>
On Wed, 31 Dec 2014, Sudip Mukherjee wrote:
> On Wed, Dec 31, 2014 at 04:04:03AM -0500, Nicholas Mc Guire wrote:
> > This is only removing the comment which is misleading as
> > wait_for_completion_timeout does not return < 0 thus there
> > never is anything to be passed on.
>
> a small doubt -
> i am seeing that:
> unsigned long wait_for_completion_timeout() is calling
> long wait_for_common() which is again calling
> long __wait_for_common which is again calling
> long do_wait_for_common()
>
> now the return value from do_wait_for_common can be -ERESTARTSYS,
> so then what happens when wait_for_completion_timeout return this -ERESTARTSYS as an unsigned value ?
> it becomes a positive value, and ultimately ctx.result (which is 0) is returned.
> so then are we just ignoring the error value from do_wait_for_common() ?
>
ESTARTSYS only can be returned if state matches in do_wait_for_common
but wait_for_completion_timemout passes TASK_UNINTERRUPTIBLE
so signal_pending_state will return 0 and thus it will never
return -ERESTARTSYS.
my understanding of the callchain is:
wait_for_completion_timemout which is uninterruptible
-> wait_for_common(...TASK_UNINTERRUPTIBLE)
-> __wait_for_common(...TASK_UNINTERRUPTIBLE)
-> do_wait_for_common(...TASK_UNINTERRUPTIBLE)
-> signal_pending_state(TASK_UNINTERRUPTIBLE...)
static inline int signal_pending_state(long state, struct task_struct *p)
{
if (!(state & (TASK_INTERRUPTIBLE | TASK_WAKEKILL)))
return 0;
so wait_for_completion_timemout should return >=0 only
thx!
hofrat
> >
> > patch is against linux-next 3.19.0-rc1 -next-20141226
> >
> > Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
> > ---
> > drivers/net/wimax/i2400m/driver.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/net/wimax/i2400m/driver.c b/drivers/net/wimax/i2400m/driver.c
> > index 9c78090..0a6384e 100644
> > --- a/drivers/net/wimax/i2400m/driver.c
> > +++ b/drivers/net/wimax/i2400m/driver.c
> > @@ -197,7 +197,6 @@ int i2400m_op_reset(struct wimax_dev *wimax_dev)
> > result = -ETIMEDOUT;
> > else if (result > 0)
> > result = ctx.result;
> > - /* if result < 0, pass it on */
> > mutex_lock(&i2400m->init_mutex);
> > i2400m->reset_ctx = NULL;
> > mutex_unlock(&i2400m->init_mutex);
> > --
> > 1.7.10.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] wait_for_completion_timeout does not return < 0
From: Sudip Mukherjee @ 2014-12-31 10:50 UTC (permalink / raw)
To: Nicholas Mc Guire; +Cc: Inaky Perez-Gonzalez, linux-wimax, netdev, linux-kernel
In-Reply-To: <20141231103711.GA30533@opentech.at>
On Wed, Dec 31, 2014 at 11:37:11AM +0100, Nicholas Mc Guire wrote:
> On Wed, 31 Dec 2014, Sudip Mukherjee wrote:
>
> > On Wed, Dec 31, 2014 at 04:04:03AM -0500, Nicholas Mc Guire wrote:
> > > This is only removing the comment which is misleading as
> > > wait_for_completion_timeout does not return < 0 thus there
> > > never is anything to be passed on.
> >
> > a small doubt -
> > i am seeing that:
> > unsigned long wait_for_completion_timeout() is calling
> > long wait_for_common() which is again calling
> > long __wait_for_common which is again calling
> > long do_wait_for_common()
> >
> > now the return value from do_wait_for_common can be -ERESTARTSYS,
> > so then what happens when wait_for_completion_timeout return this -ERESTARTSYS as an unsigned value ?
> > it becomes a positive value, and ultimately ctx.result (which is 0) is returned.
> > so then are we just ignoring the error value from do_wait_for_common() ?
> >
>
> ESTARTSYS only can be returned if state matches in do_wait_for_common
> but wait_for_completion_timemout passes TASK_UNINTERRUPTIBLE
> so signal_pending_state will return 0 and thus it will never
> return -ERESTARTSYS.
>
> my understanding of the callchain is:
> wait_for_completion_timemout which is uninterruptible
> -> wait_for_common(...TASK_UNINTERRUPTIBLE)
> -> __wait_for_common(...TASK_UNINTERRUPTIBLE)
> -> do_wait_for_common(...TASK_UNINTERRUPTIBLE)
> -> signal_pending_state(TASK_UNINTERRUPTIBLE...)
>
> static inline int signal_pending_state(long state, struct task_struct *p)
> {
> if (!(state & (TASK_INTERRUPTIBLE | TASK_WAKEKILL)))
> return 0;
>
> so wait_for_completion_timemout should return >=0 only
doubt cleared.
thanks
sudip
>
> thx!
> hofrat
>
> > >
> > > patch is against linux-next 3.19.0-rc1 -next-20141226
> > >
> > > Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
> > > ---
> > > drivers/net/wimax/i2400m/driver.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/net/wimax/i2400m/driver.c b/drivers/net/wimax/i2400m/driver.c
> > > index 9c78090..0a6384e 100644
> > > --- a/drivers/net/wimax/i2400m/driver.c
> > > +++ b/drivers/net/wimax/i2400m/driver.c
> > > @@ -197,7 +197,6 @@ int i2400m_op_reset(struct wimax_dev *wimax_dev)
> > > result = -ETIMEDOUT;
> > > else if (result > 0)
> > > result = ctx.result;
> > > - /* if result < 0, pass it on */
> > > mutex_lock(&i2400m->init_mutex);
> > > i2400m->reset_ctx = NULL;
> > > mutex_unlock(&i2400m->init_mutex);
> > > --
> > > 1.7.10.4
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
From: Sergei Shtylyov @ 2014-12-31 11:22 UTC (permalink / raw)
To: Fu, Zhonghui, brudley, Arend van Spriel, Franky Lin, meuleman,
kvalo, linville, pieterpg, hdegoede, wens, linux-wireless,
brcm80211-dev-list, netdev, linux-kernel
In-Reply-To: <54A3B1B4.7090705@linux.intel.com>
Hello.
On 12/31/2014 11:20 AM, Fu, Zhonghui wrote:
> From e34419970a07bfcd365f9c66bdfa552188a0cd26 Mon Sep 17 00:00:00 2001
> From: Zhonghui Fu <zhonghui.fu@linux.intel.com>
> Date: Mon, 29 Dec 2014 21:25:31 +0800
> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
> WiFi chip has 2 SDIO functions, and PM core will trigger
> twice suspend/resume operations for one WiFi chip to do
> the same things. This patch avoid this case.
> Signed-off-by: Zhonghui Fu <zhonghui.fu@linux.intel.com>
> ---
> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 19 +++++++++++++++++--
> 1 files changed, 17 insertions(+), 2 deletions(-)
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
> index 3c06e93..eee7818 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
> @@ -1139,11 +1139,18 @@ void brcmf_sdio_wowl_config(struct device *dev, bool enabled)
> static int brcmf_ops_sdio_suspend(struct device *dev)
> {
> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
> + struct brcmf_sdio_dev *sdiodev;
> mmc_pm_flag_t sdio_flags;
> + struct sdio_func *func = dev_to_sdio_func(dev);
>
> brcmf_dbg(SDIO, "Enter\n");
>
> + if (func->num == 2) {
> + return 0;
> + }
{} not needed.
[...]
> @@ -1164,9 +1171,17 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
> static int brcmf_ops_sdio_resume(struct device *dev)
> {
> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
> + struct brcmf_sdio_dev *sdiodev;
> + struct sdio_func *func = dev_to_sdio_func(dev);
>
> brcmf_dbg(SDIO, "Enter\n");
> +
> + if (func->num == 2) {
> + return 0;
> + }
Same here.
[...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] can: kvaser_usb: Add support for the Usbcan-II family
From: Olivier Sobrie @ 2014-12-31 12:13 UTC (permalink / raw)
To: Ahmed S. Darwish
Cc: Oliver Hartkopp, Wolfgang Grandegger, Marc Kleine-Budde,
David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML
In-Reply-To: <20141230153326.GA3798@linux>
On Tue, Dec 30, 2014 at 10:33:26AM -0500, Ahmed S. Darwish wrote:
> On Sun, Dec 28, 2014 at 10:51:34PM +0100, Olivier Sobrie wrote:
> [...]
> > > > >
> > > > > + if (LEAF_PRODUCT_ID(id->idProduct)) {
> > > > > + dev->family = KVASER_LEAF;
> > > > > + dev->max_channels = LEAF_MAX_NET_DEVICES;
> > > > > + } else if (USBCAN_PRODUCT_ID(id->idProduct)) {
> > > > > + dev->family = KVASER_USBCAN;
> > > > > + dev->max_channels = USBCAN_MAX_NET_DEVICES;
> > > > > + } else {
> > > > > + dev_err(&intf->dev, "Product ID (%d) does not belong to any "
> > > > > + "known Kvaser USB family", id->idProduct);
> > > > > + return -ENODEV;
> > > > > + }
> > > > > +
> > > >
> > > > Is it really required to keep max_channels in the kvaser_usb structure?
> > > > If I looked correctly, you use this variable as a replacement for
> > > > MAX_NET_DEVICES in the code and MAX_NET_DEVICES is only used in probe
> > > > and disconnect functions. I think it can even be replaced by nchannels
> > > > in the disconnect path. So I also think that it don't need to be in the
> > > > kvaser_usb structure.
> > > >
> > >
> > > hmmm.. given the current state of error arbitration explained
> > > above, where I cannot accept a dev->nchannels > 2, I guess we
> > > have two options:
> > >
> > > a) Remove max_channels, and hardcode the channels count
> > > correctness logic as follows:
> > >
> > > dev->nchannels = msg.u.cardinfo.nchannels;
> > > if ((dev->family == USBCAN && dev->nchannels > USBCAN_MAX_NET_DEVICES)
> > > || (dev->family == LEAF && dev->nchannels > LEAF_MAX_NET_DEVICES))
> > > return -EINVAL
> > >
> > > b) Leave max_channels in 'struct kvaser_usb' as is.
> > >
> > > I personally prefer the solution at 'b)' but I can do it as
> > > in 'a)' if you prefer :-)
> >
> > Keeping max_channels in the kvaser_usb structure is useless because it
> > is only used in one function that is called in the probe function.
> >
> > I would prefer to have:
> > if (dev->nchannels > MAX_NET_DEVICES)
> > return -EINVAL
> >
> > if ((dev->family == USBCAN) &&
> > (dev->nchannels > MAX_USBCAN_NET_DEVICES))
> > return -EINVAL
> >
> > You can remove LEAF_MAX_NET_DEVICES which is not used, keep
> > MAX_NET_DEVICES equals to 3 and remove the MAX() macro.
> > The test specific to the USBCAN family can eventually be moved in the
> > kvaser_usb_probe() function.
> >
>
> Quite nice, will do it that way in v3.
>
Thank you.
Please also check your patches with scripts/checkpatch.pl.
I see several warnings when I run it. Please fix them.
All the best for New Year's Eve,
--
Olivier
^ permalink raw reply
* [PATCH net-next] net: skbuff: don't zero tc members when freeing skb
From: Florian Westphal @ 2014-12-31 12:33 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
Not needed, only four cases:
- kfree_skb (or one of its aliases).
Don't need to zero, memory will be freed.
- kfree_skb_partial and head was stolen: memory will be freed.
- skb_morph: The skb header fields (including tc ones) will be
copied over from the 'to-be-morphed' skb right after
skb_release_head_state returns.
- skb_segment: Same as before, all the skb header
fields are copied over from the original skb right away.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/core/skbuff.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index ae13ef6..8e20bfa 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -677,13 +677,6 @@ static void skb_release_head_state(struct sk_buff *skb)
#if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
nf_bridge_put(skb->nf_bridge);
#endif
-/* XXX: IS this still necessary? - JHS */
-#ifdef CONFIG_NET_SCHED
- skb->tc_index = 0;
-#ifdef CONFIG_NET_CLS_ACT
- skb->tc_verd = 0;
-#endif
-#endif
}
/* Free everything but the sk_buff shell. */
--
2.0.5
^ permalink raw reply related
* Re: net.git: Call-trace after "Merge branch 'netlink_multicast'"
From: Sedat Dilek @ 2014-12-31 13:17 UTC (permalink / raw)
To: David Miller; +Cc: Johannes Berg, netdev@vger.kernel.org, Wu Fengguang
In-Reply-To: <20141229.163311.498586171360350188.davem@davemloft.net>
On Mon, Dec 29, 2014 at 10:33 PM, David Miller <davem@davemloft.net> wrote:
> From: Sedat Dilek <sedat.dilek@gmail.com>
> Date: Sun, 28 Dec 2014 10:34:51 +0100
>
>> On Sun, Dec 28, 2014 at 8:54 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>> Just a small thing, if you look at this...
>>>
>>> With gcc-4.9.2 I see this warning in my logs...
>>>
>>> net/netlink/genetlink.c: In function 'genl_bind':
>>> net/netlink/genetlink.c:1018:2: warning: 'err' may be used
>>> uninitialized in this function [-Wmaybe-uninitialized]
>>>
>>
>> Attached patch fixes the issue for me.
>
> Ok since the user can request arbitrary multicast groups, we cannot
> warn in this situation.
>
> And since initializing 'err' to zero makes the whole 'found'
> variable completely unnecessary, we can delete that too.
>
> This is the final patch I am applying, thanks for all of your
> help.
>
> ====================
> [PATCH] genetlink: A genl_bind() to an out-of-range multicast group should not WARN().
>
> Users can request to bind to arbitrary multicast groups, so warning
> when the requested group number is out of range is not appropriate.
>
> And with the warning removed, and the 'err' variable properly given
> an initial value, we can remove 'found' altogether.
>
> Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Thanks Dave for pushing this!
Guten Rutsch (Happy new year),
- Sedat -
> ---
> net/netlink/genetlink.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> index 91566ed..2e11061 100644
> --- a/net/netlink/genetlink.c
> +++ b/net/netlink/genetlink.c
> @@ -985,8 +985,7 @@ static struct genl_multicast_group genl_ctrl_groups[] = {
>
> static int genl_bind(struct net *net, int group)
> {
> - int i, err;
> - bool found = false;
> + int i, err = 0;
>
> down_read(&cb_lock);
> for (i = 0; i < GENL_FAM_TAB_SIZE; i++) {
> @@ -1003,16 +1002,12 @@ static int genl_bind(struct net *net, int group)
> err = f->mcast_bind(net, fam_grp);
> else
> err = 0;
> - found = true;
> break;
> }
> }
> }
> up_read(&cb_lock);
>
> - if (WARN_ON(!found))
> - err = 0;
> -
> return err;
> }
>
> --
> 1.7.11.7
>
^ permalink raw reply
* tcp: Do not apply TSO segment limit to non-TSO packets
From: Herbert Xu @ 2014-12-31 13:39 UTC (permalink / raw)
To: Thomas Jarosch
Cc: netdev, edumazet, Steffen Klassert, Ben Hutchings,
David S. Miller
In-Reply-To: <20141201102522.GA16579@gondor.apana.org.au>
On Mon, Dec 01, 2014 at 06:25:22PM +0800, Herbert Xu wrote:
> Thomas Jarosch <thomas.jarosch@intra2net.com> wrote:
> >
> > When I revert it, even kernel v3.18-rc6 starts working.
> > But I doubt this is the root problem, may be just hiding another issue.
>
> Can you do a tcpdump with this patch reverted? I would like to
> see the size of the packets that are sent out vs. the ICMP message
> that came back.
Thanks for providing the data. Here is a patch that should fix
the problem.
-- >8 --
Thomas Jarosch reported IPsec TCP stalls when a PMTU event occurs.
In fact the problem was completely unrelated to IPsec. The bug is
also reproducible if you just disable TSO/GSO.
The problem is that when the MSS goes down, existing queued packet
on the TX queue that have not been transmitted yet all look like
TSO packets and get treated as such.
This then triggers a bug where tcp_mss_split_point tells us to
generate a zero-sized packet on the TX queue. Once that happens
we're screwed because the zero-sized packet can never be removed
by ACKs.
Fixes: 1485348d242 ("tcp: Apply device TSO segment limit earlier")
Reported-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 7f18262..65caf8b 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2019,7 +2019,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
if (unlikely(!tcp_snd_wnd_test(tp, skb, mss_now)))
break;
- if (tso_segs == 1) {
+ if (tso_segs == 1 || !max_segs) {
if (unlikely(!tcp_nagle_test(tp, skb, mss_now,
(tcp_skb_is_last(sk, skb) ?
nonagle : TCP_NAGLE_PUSH))))
@@ -2032,7 +2032,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
}
limit = mss_now;
- if (tso_segs > 1 && !tcp_urg_mode(tp))
+ if (tso_segs > 1 && max_segs && !tcp_urg_mode(tp))
limit = tcp_mss_split_point(sk, skb, mss_now,
min_t(unsigned int,
cwnd_quota,
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: tcp: Do not apply TSO segment limit to non-TSO packets
From: Herbert Xu @ 2014-12-31 13:42 UTC (permalink / raw)
To: Thomas Jarosch
Cc: netdev, edumazet, Steffen Klassert, Ben Hutchings,
David S. Miller
In-Reply-To: <20141231133923.GA30248@gondor.apana.org.au>
On Thu, Jan 01, 2015 at 12:39:23AM +1100, Herbert Xu wrote:
>
> Thomas Jarosch reported IPsec TCP stalls when a PMTU event occurs.
>
> In fact the problem was completely unrelated to IPsec. The bug is
> also reproducible if you just disable TSO/GSO.
This raises two interesting questions.
Firstly not many people test non-TSO code paths anymore so bugs
are likely to persist for a long time there. Perhaps it's time
to remove the non-TSO code path altogether? The GSO code path
should provide enough speed-up in terms of boosting the effective
MTU to offset the cost of copying.
Secondly why are we dealing with hardware TSO segment limits
by limiting the size of the TSO packet in the TCP stack? Surely
in this case GSO is free since there won't be any copying?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: Add Transparent Ethernet Bridging GRO support.
From: Jesse Gross @ 2014-12-31 14:30 UTC (permalink / raw)
To: Or Gerlitz; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CAJ3xEMhSJN5yNm69Hfpe3L9kv0kDx=hSABkD_NPz2dsQDt3Xnw@mail.gmail.com>
On Wed, Dec 31, 2014 at 4:19 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Wed, Dec 31, 2014 at 5:10 AM, Jesse Gross <jesse@nicira.com> wrote:
>> Currently the only tunnel protocol that supports GRO with encapsulated
>> Ethernet is VXLAN. This pulls out the Ethernet code into a proper layer
>> so that it can be used by other tunnel protocols such as GRE and Geneve.
>
> Hi Jesse,
>
> Thanks for taking care of that, I also had it coded under the
> intention of adding GRO support for OVS's TEB based GRE, but didn't
> make it to submit before your post... anyway, I would recommend that
> you break this patch into two:
>
> 1. basic TEB GRO support
> 2. refactoring of the VXLAN GRO logic to use it
This patch is really just moving code so breaking it into two steps
would essentially mean introducing duplicate code and then deleting
the first version in the next patch. It's already a pretty short patch
and I think splitting it would actually make it harder to verify that
it is correct.
^ permalink raw reply
* Re: [PATCH net-next v1 0/5]: ixgbevf: Allow querying VFs RSS indirection table and key
From: Jeff Kirsher @ 2014-12-31 16:01 UTC (permalink / raw)
To: Vlad Zolotarov; +Cc: netdev, gleb, avi
In-Reply-To: <1420019519-18139-1-git-send-email-vladz@cloudius-systems.com>
[-- Attachment #1: Type: text/plain, Size: 739 bytes --]
On Wed, 2014-12-31 at 11:51 +0200, Vlad Zolotarov wrote:
> Add the ethtool ops to VF driver to allow querying the RSS indirection
> table
> and RSS Random Key.
>
> - PF driver: Add new VF-PF channel commands.
> - VF driver: Utilize these new commands and add the corresponding
> ethtool callbacks.
>
> New in v1 (compared to RFC):
> - Use "if-else" statement instead of a "switch-case" for a single
> option case.
> More specifically: in cases where the newly added API version is
> the only one
> allowed. We may consider using a "switch-case" back again when
> the list of
> allowed API versions in these specific places grows up.
Thanks Vlad, I will add your series to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v1 0/5]: ixgbevf: Allow querying VFs RSS indirection table and key
From: Vlad Zolotarov @ 2014-12-31 16:20 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: netdev, gleb, avi
In-Reply-To: <1420041700.31582.36.camel@jtkirshe-mobl>
On 12/31/14 18:01, Jeff Kirsher wrote:
> On Wed, 2014-12-31 at 11:51 +0200, Vlad Zolotarov wrote:
>> Add the ethtool ops to VF driver to allow querying the RSS indirection
>> table
>> and RSS Random Key.
>>
>> - PF driver: Add new VF-PF channel commands.
>> - VF driver: Utilize these new commands and add the corresponding
>> ethtool callbacks.
>>
>> New in v1 (compared to RFC):
>> - Use "if-else" statement instead of a "switch-case" for a single
>> option case.
>> More specifically: in cases where the newly added API version is
>> the only one
>> allowed. We may consider using a "switch-case" back again when
>> the list of
>> allowed API versions in these specific places grows up.
> Thanks Vlad, I will add your series to my queue.
Great! Thanks a lot Jeff!
Happy New Year to everybody!
^ permalink raw reply
* Re: [PATCH net-next v1 4/5] ixgbevf: Add RSS Key query code
From: Jeff Kirsher @ 2014-12-31 16:28 UTC (permalink / raw)
To: Vlad Zolotarov; +Cc: netdev, gleb, avi
In-Reply-To: <1420019519-18139-5-git-send-email-vladz@cloudius-systems.com>
[-- Attachment #1: Type: text/plain, Size: 818 bytes --]
On Wed, 2014-12-31 at 11:51 +0200, Vlad Zolotarov wrote:
> Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
> ---
> New in v1 (compared to RFC):
> - Use "if-else" statement instead of a "switch-case" for a single
> option case
> (in ixgbevf_get_rss_key()).
>
> ---
> drivers/net/ethernet/intel/ixgbevf/mbx.h | 2 ++
> drivers/net/ethernet/intel/ixgbevf/vf.c | 44
> ++++++++++++++++++++++++++++++++
> drivers/net/ethernet/intel/ixgbevf/vf.h | 1 +
> 3 files changed, 47 insertions(+)
Just caught this now, sorry but your patch description is sparse (i.e.
non-existent). I know that the title of the patch pretty much tells
what you are doing, but it would be nice to have a bit more detail as to
why (like your first patch).
Same goes for patch 5 of the series as well.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH net] openvswitch: Consistently include VLAN header in flow and port stats.
From: Ben Pfaff @ 2014-12-31 16:45 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, dev-yBygre7rU0TnMu66kgdUjQ
Cc: Ben Pfaff, Motonori Shindo
Until now, when VLAN acceleration was in use, the bytes of the VLAN header
were not included in port or flow byte counters. They were however
included when VLAN acceleration was not used. This commit corrects the
inconsistency, by always including the VLAN header in byte counters.
Previous discussion at
http://openvswitch.org/pipermail/dev/2014-December/049521.html
Reported-by: Motonori Shindo <mshindo@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
---
net/openvswitch/flow.c | 5 +++--
net/openvswitch/vport.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index 70bef2a..da2fae0 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -70,6 +70,7 @@ void ovs_flow_stats_update(struct sw_flow *flow, __be16 tcp_flags,
{
struct flow_stats *stats;
int node = numa_node_id();
+ int len = skb->len + (vlan_tx_tag_present(skb) ? VLAN_HLEN : 0);
stats = rcu_dereference(flow->stats[node]);
@@ -105,7 +106,7 @@ void ovs_flow_stats_update(struct sw_flow *flow, __be16 tcp_flags,
if (likely(new_stats)) {
new_stats->used = jiffies;
new_stats->packet_count = 1;
- new_stats->byte_count = skb->len;
+ new_stats->byte_count = len;
new_stats->tcp_flags = tcp_flags;
spin_lock_init(&new_stats->lock);
@@ -120,7 +121,7 @@ void ovs_flow_stats_update(struct sw_flow *flow, __be16 tcp_flags,
stats->used = jiffies;
stats->packet_count++;
- stats->byte_count += skb->len;
+ stats->byte_count += len;
stats->tcp_flags |= tcp_flags;
unlock:
spin_unlock(&stats->lock);
diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
index 53f3ebb..2034c6d 100644
--- a/net/openvswitch/vport.c
+++ b/net/openvswitch/vport.c
@@ -480,7 +480,7 @@ void ovs_vport_receive(struct vport *vport, struct sk_buff *skb,
stats = this_cpu_ptr(vport->percpu_stats);
u64_stats_update_begin(&stats->syncp);
stats->rx_packets++;
- stats->rx_bytes += skb->len;
+ stats->rx_bytes += skb->len + (vlan_tx_tag_present(skb) ? VLAN_HLEN : 0);
u64_stats_update_end(&stats->syncp);
OVS_CB(skb)->input_vport = vport;
--
2.1.3
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply related
* [PATCH] net: ethernet: intel: i40e: i40e_fcoe.c: Remove unused function
From: Rickard Strandqvist @ 2014-12-31 16:48 UTC (permalink / raw)
To: Jeff Kirsher, Jesse Brandeburg
Cc: Rickard Strandqvist, Bruce Allan, Carolyn Wyborny, Don Skidmore,
Greg Rose, Matthew Vick, John Ronciak, Mitch Williams, Linux NICS,
e1000-devel, netdev, linux-kernel
Remove the function i40e_rx_is_fip() that is not used anywhere.
This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/net/ethernet/intel/i40e/i40e_fcoe.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_fcoe.c b/drivers/net/ethernet/intel/i40e/i40e_fcoe.c
index 5d01db1..20a5bfa 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_fcoe.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_fcoe.c
@@ -39,15 +39,6 @@
#include "i40e_fcoe.h"
/**
- * i40e_rx_is_fip - returns true if the rx packet type is FIP
- * @ptype: the packet type field from rx descriptor write-back
- **/
-static inline bool i40e_rx_is_fip(u16 ptype)
-{
- return ptype == I40E_RX_PTYPE_L2_FIP_PAY2;
-}
-
-/**
* i40e_rx_is_fcoe - returns true if the rx packet type is FCoE
* @ptype: the packet type field from rx descriptor write-back
**/
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next v2 0/2] bridge: support for vlan range in setlink/dellink
From: roopa @ 2014-12-31 16:48 UTC (permalink / raw)
To: netdev, hemminger, vyasevic; +Cc: sfeldma, wkok, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This series adds new netlink attribute to represent vlan range.
Will post corresponding iproute2 patches if these get accepted.
v1-> v2
- changed patches to use a nested list of IFLA_BRIDGE_VLAN_INFO
as suggested by scott feldman
- dropped notification changes from the series. Will post them
separately after this range message is accepted.
Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Roopa Prabhu (2):
bridge: new attribute and flags to represent vlan info lists and
ranges
bridge: modify bridge af spec parser to accomodate vlan list and
ranges
include/uapi/linux/if_bridge.h | 4 ++
net/bridge/br_netlink.c | 118 ++++++++++++++++++++++++++++++----------
2 files changed, 92 insertions(+), 30 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH net-next v2 1/2] bridge: new attribute and flags to represent vlan info lists and ranges
From: roopa @ 2014-12-31 16:48 UTC (permalink / raw)
To: netdev, hemminger, vyasevic; +Cc: sfeldma, wkok, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds (as suggested by scott feldman),
- new netlink attribute IFLA_BRIDGE_VLAN_INFO_LIST to represent
vlan list
- And bridge_vlan_info flags BRIDGE_VLAN_INFO_RANGE_START and
BRIDGE_VLAN_INFO_RANGE_END to indicate start and end of vlan range
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
include/uapi/linux/if_bridge.h | 4 ++++
net/bridge/br_netlink.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
index b03ee8f..fa468aa 100644
--- a/include/uapi/linux/if_bridge.h
+++ b/include/uapi/linux/if_bridge.h
@@ -112,12 +112,14 @@ struct __fdb_entry {
* [IFLA_BRIDGE_FLAGS]
* [IFLA_BRIDGE_MODE]
* [IFLA_BRIDGE_VLAN_INFO]
+ * [IFLA_BRIDGE_VLAN_INFO_LIST]
* }
*/
enum {
IFLA_BRIDGE_FLAGS,
IFLA_BRIDGE_MODE,
IFLA_BRIDGE_VLAN_INFO,
+ IFLA_BRIDGE_VLAN_INFO_LIST,
__IFLA_BRIDGE_MAX,
};
#define IFLA_BRIDGE_MAX (__IFLA_BRIDGE_MAX - 1)
@@ -125,6 +127,8 @@ enum {
#define BRIDGE_VLAN_INFO_MASTER (1<<0) /* Operate on Bridge device as well */
#define BRIDGE_VLAN_INFO_PVID (1<<1) /* VLAN is PVID, ingress untagged */
#define BRIDGE_VLAN_INFO_UNTAGGED (1<<2) /* VLAN egresses untagged */
+#define BRIDGE_VLAN_INFO_RANGE_START (1<<3) /* VLAN is start of vlan range */
+#define BRIDGE_VLAN_INFO_RANGE_END (1<<4) /* VLAN is end of vlan range */
struct bridge_vlan_info {
__u16 flags;
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 9f5eb55..492ef6a 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -223,6 +223,7 @@ static const struct nla_policy ifla_br_policy[IFLA_MAX+1] = {
[IFLA_BRIDGE_MODE] = { .type = NLA_U16 },
[IFLA_BRIDGE_VLAN_INFO] = { .type = NLA_BINARY,
.len = sizeof(struct bridge_vlan_info), },
+ [IFLA_BRIDGE_VLAN_INFO_LIST] = { .type = NLA_NESTED, },
};
static int br_afspec(struct net_bridge *br,
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next v2 2/2] bridge: modify bridge af spec parser to accomodate vlan list and ranges
From: roopa @ 2014-12-31 16:48 UTC (permalink / raw)
To: netdev, hemminger, vyasevic; +Cc: sfeldma, wkok, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch modifies br_afspec to parse incoming IFLA_BRIDGE_VLAN_INFO_LIST
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
net/bridge/br_netlink.c | 115 ++++++++++++++++++++++++++++++++++-------------
1 file changed, 85 insertions(+), 30 deletions(-)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 492ef6a..bcba9d2 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -226,53 +226,108 @@ static const struct nla_policy ifla_br_policy[IFLA_MAX+1] = {
[IFLA_BRIDGE_VLAN_INFO_LIST] = { .type = NLA_NESTED, },
};
+static int br_vlan_info(struct net_bridge *br, struct net_bridge_port *p,
+ int cmd, struct bridge_vlan_info *vinfo)
+{
+ int err = 0;
+
+ switch (cmd) {
+ case RTM_SETLINK:
+ if (p) {
+ err = nbp_vlan_add(p, vinfo->vid, vinfo->flags);
+ if (err)
+ break;
+
+ if (vinfo->flags & BRIDGE_VLAN_INFO_MASTER)
+ err = br_vlan_add(p->br, vinfo->vid,
+ vinfo->flags);
+ } else {
+ err = br_vlan_add(br, vinfo->vid, vinfo->flags);
+ }
+ break;
+
+ case RTM_DELLINK:
+ if (p) {
+ nbp_vlan_delete(p, vinfo->vid);
+ if (vinfo->flags & BRIDGE_VLAN_INFO_MASTER)
+ br_vlan_delete(p->br, vinfo->vid);
+ } else {
+ br_vlan_delete(br, vinfo->vid);
+ }
+ break;
+ }
+
+ return err;
+}
+
static int br_afspec(struct net_bridge *br,
struct net_bridge_port *p,
struct nlattr *af_spec,
int cmd)
{
struct nlattr *tb[IFLA_BRIDGE_MAX+1];
+ struct nlattr *attr;
int err = 0;
+ int rem;
err = nla_parse_nested(tb, IFLA_BRIDGE_MAX, af_spec, ifla_br_policy);
if (err)
return err;
if (tb[IFLA_BRIDGE_VLAN_INFO]) {
- struct bridge_vlan_info *vinfo;
-
- vinfo = nla_data(tb[IFLA_BRIDGE_VLAN_INFO]);
-
- if (!vinfo->vid || vinfo->vid >= VLAN_VID_MASK)
- return -EINVAL;
-
- switch (cmd) {
- case RTM_SETLINK:
- if (p) {
- err = nbp_vlan_add(p, vinfo->vid, vinfo->flags);
- if (err)
- break;
-
- if (vinfo->flags & BRIDGE_VLAN_INFO_MASTER)
- err = br_vlan_add(p->br, vinfo->vid,
- vinfo->flags);
- } else
- err = br_vlan_add(br, vinfo->vid, vinfo->flags);
-
- break;
-
- case RTM_DELLINK:
- if (p) {
- nbp_vlan_delete(p, vinfo->vid);
- if (vinfo->flags & BRIDGE_VLAN_INFO_MASTER)
- br_vlan_delete(p->br, vinfo->vid);
- } else
- br_vlan_delete(br, vinfo->vid);
- break;
+ attr = tb[IFLA_BRIDGE_VLAN_INFO];
+ if (nla_len(attr) != sizeof(struct bridge_vlan_info))
+ goto err_inval;
+
+ err = br_vlan_info(br, p, cmd,
+ (struct bridge_vlan_info *)nla_data(attr));
+
+ } else if (tb[IFLA_BRIDGE_VLAN_INFO_LIST]) {
+ struct bridge_vlan_info *vinfo_start = NULL;
+ struct bridge_vlan_info *vinfo = NULL;
+
+ nla_for_each_nested(attr, tb[IFLA_BRIDGE_VLAN_INFO_LIST], rem) {
+ if (nla_len(attr) != sizeof(struct bridge_vlan_info) ||
+ nla_type(attr) != IFLA_BRIDGE_VLAN_INFO)
+ goto err_inval;
+ vinfo = nla_data(attr);
+ if (vinfo->flags & BRIDGE_VLAN_INFO_RANGE_START) {
+ if (vinfo_start)
+ goto err_inval;
+ vinfo_start = vinfo;
+ continue;
+ }
+
+ if (vinfo_start) {
+ int v;
+
+ if (!(vinfo->flags & BRIDGE_VLAN_INFO_RANGE_END))
+ goto err_inval;
+
+ if (vinfo->vid < vinfo_start->vid)
+ goto err_inval;
+
+ for (v = vinfo_start->vid; v <= vinfo->vid;
+ v++) {
+ vinfo_start->vid = v;
+ err = br_vlan_info(br, p, cmd,
+ vinfo_start);
+ if (err)
+ break;
+ }
+ vinfo_start = NULL;
+ } else {
+ err = br_vlan_info(br, p, cmd, vinfo);
+ }
+ if (err)
+ break;
}
}
return err;
+
+err_inval:
+ return -EINVAL;
}
static const struct nla_policy br_port_policy[IFLA_BRPORT_MAX + 1] = {
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH net-next v1 4/5] ixgbevf: Add RSS Key query code
From: Vlad Zolotarov @ 2014-12-31 17:01 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: netdev, gleb, avi
In-Reply-To: <1420043307.31582.53.camel@jtkirshe-mobl>
On 12/31/14 18:28, Jeff Kirsher wrote:
> On Wed, 2014-12-31 at 11:51 +0200, Vlad Zolotarov wrote:
>> Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
>> ---
>> New in v1 (compared to RFC):
>> - Use "if-else" statement instead of a "switch-case" for a single
>> option case
>> (in ixgbevf_get_rss_key()).
>>
>> ---
>> drivers/net/ethernet/intel/ixgbevf/mbx.h | 2 ++
>> drivers/net/ethernet/intel/ixgbevf/vf.c | 44
>> ++++++++++++++++++++++++++++++++
>> drivers/net/ethernet/intel/ixgbevf/vf.h | 1 +
>> 3 files changed, 47 insertions(+)
> Just caught this now, sorry but your patch description is sparse (i.e.
> non-existent). I know that the title of the patch pretty much tells
> what you are doing, but it would be nice to have a bit more detail as to
> why (like your first patch).
>
> Same goes for patch 5 of the series as well.
No problema. ;)
Will send the v2.
^ 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