summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorOphir Munk <ophirmu@mellanox.com>2018-02-14 11:32:19 +0000
committerThomas Monjalon <thomas@monjalon.net>2018-02-14 15:42:39 +0100
commitba2f43464ed53fd1358cf7b1f483103c616f341c (patch)
tree8dcc1991d84b61d3e676eb43c271492eced42a27
parentb69e737a65b7cb6a96368348e4eee93496bda727 (diff)
downloaddpdk-draft-windows-ba2f43464ed53fd1358cf7b1f483103c616f341c.zip
dpdk-draft-windows-ba2f43464ed53fd1358cf7b1f483103c616f341c.tar.gz
dpdk-draft-windows-ba2f43464ed53fd1358cf7b1f483103c616f341c.tar.xz
net/tap: fix promiscuous rules double insertions
Running testpmd command "port stop all" followed by command "port start all" may result in a TAP error: PMD: Kernel refused TC filter rule creation (17): File exists Root cause analysis: during the execution of "port start all" command testpmd calls rte_eth_promiscuous_enable() while during the execution of "port stop all" command testpmd does not call rte_eth_promiscuous_disable(). As a result the TAP PMD is trying to add tc (traffic control command) promiscuous rules to the remote netvsc device consecutively. From the kernel point of view it is seen as an attempt to add the same rule more than once. In recent kernels (e.g. version 4.13) this attempt is rejected with a "File exists" error. In less recent kernels (e.g. version 4.4) the same rule may have been successfully accepted twice, which is undesirable. In the corrupted code every tc promiscuous rule included a different handle number parameter. If instead an identical handle number is used for all tc promiscuous rules - all kernels will reject the second identical rule with a "File exists" error, which is easy to identify and to silently ignore. Fixes: 2bc06869cd94 ("net/tap: add remote netdevice traffic capture") Cc: stable@dpdk.org Signed-off-by: Ophir Munk <ophirmu@mellanox.com> Acked-by: Pascal Mazon <pascal.mazon@6wind.com>
-rw-r--r--drivers/net/tap/tap_flow.c11
1 files changed, 11 insertions, 0 deletions
diff --git a/drivers/net/tap/tap_flow.c b/drivers/net/tap/tap_flow.c
index 65657f0..551b2d8 100644
--- a/drivers/net/tap/tap_flow.c
+++ b/drivers/net/tap/tap_flow.c
@@ -123,6 +123,7 @@ enum key_status_e {
};
#define ISOLATE_HANDLE 1
+#define REMOTE_PROMISCUOUS_HANDLE 2
struct rte_flow {
LIST_ENTRY(rte_flow) next; /* Pointer to the next rte_flow structure */
@@ -1692,9 +1693,15 @@ int tap_flow_implicit_create(struct pmd_internals *pmd,
* The ISOLATE rule is always present and must have a static handle, as
* the action is changed whether the feature is enabled (DROP) or
* disabled (PASSTHRU).
+ * There is just one REMOTE_PROMISCUOUS rule in all cases. It should
+ * have a static handle such that adding it twice will fail with EEXIST
+ * with any kernel version. Remark: old kernels may falsely accept the
+ * same REMOTE_PROMISCUOUS rules if they had different handles.
*/
if (idx == TAP_ISOLATE)
remote_flow->msg.t.tcm_handle = ISOLATE_HANDLE;
+ else if (idx == TAP_REMOTE_PROMISC)
+ remote_flow->msg.t.tcm_handle = REMOTE_PROMISCUOUS_HANDLE;
else
tap_flow_set_handle(remote_flow);
if (priv_flow_process(pmd, attr, items, actions, NULL,
@@ -1709,12 +1716,16 @@ int tap_flow_implicit_create(struct pmd_internals *pmd,
}
err = tap_nl_recv_ack(pmd->nlsk_fd);
if (err < 0) {
+ /* Silently ignore re-entering remote promiscuous rule */
+ if (errno == EEXIST && idx == TAP_REMOTE_PROMISC)
+ goto success;
RTE_LOG(ERR, PMD,
"Kernel refused TC filter rule creation (%d): %s\n",
errno, strerror(errno));
goto fail;
}
LIST_INSERT_HEAD(&pmd->implicit_flows, remote_flow, next);
+success:
return 0;
fail:
if (remote_flow)