Good job. Looks ok to me.
Acked-by: Pascal Mazon
On 14/02/2018 12:32, Ophir Munk wrote:
> 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: sta...@dpdk.org
>
> Signed-off-by: Ophir Munk
> ---
> v1: initial version
> v2: add detailed commit message
> v3: textual fixes to commit message and code comments
>
> drivers/net/tap/tap_flow.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> 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)
