DPDK patches and discussions
 help / color / mirror / Atom feed
From: Pascal Mazon <pascal.mazon@6wind.com>
To: Ophir Munk <ophirmu@mellanox.com>, dev@dpdk.org
Cc: Thomas Monjalon <thomas@monjalon.net>,
	Olga Shern <olgas@mellanox.com>,
	stable@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] net/tap: fix promiscuous rules double insersions
Date: Wed, 14 Feb 2018 09:50:36 +0100	[thread overview]
Message-ID: <a4b42b2a-4286-5036-a66b-0ba100320503@6wind.com> (raw)
In-Reply-To: <1518546947-20932-1-git-send-email-ophirmu@mellanox.com>

Hi Ophir,

Typo in title: s/insersions/insertions/

I'm ok on principle, I have just a few comments inline.

Regards,
Pascal

On 13/02/2018 19:35, 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_enable().
Shouldn't it be 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 accepted twice successfully, which is undesirable.
>
> In the corrupted code every tc promiscuous rule included a different
> handle number parameter. If instead an identical handle number parameter is
> used for all tc promiscuous rules - all kernels will reject the second
> 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>
> ---
> v2: add detailed commit message
>
>  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..d1f4a52 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_PREMISCUOUS rules if they had different handles.
s/PREMISCUOUS/PROMISCUOUS/
>  	 */
>  	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);
Are we sure the previous rule is still in the registered implicit flows?
> +success:
>  	return 0;
>  fail:
>  	if (remote_flow)

  reply	other threads:[~2018-02-14  8:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-13 17:16 [dpdk-dev] [PATCH v1] " Ophir Munk
2018-02-13 18:35 ` [dpdk-dev] [PATCH v2] " Ophir Munk
2018-02-14  8:50   ` Pascal Mazon [this message]
2018-02-14 11:23     ` Ophir Munk
2018-02-14 14:25     ` Ophir Munk
2018-02-14 11:32   ` [dpdk-dev] [PATCH v3] net/tap: fix promiscuous rules double insertions Ophir Munk
2018-02-14 13:13     ` Pascal Mazon
2018-02-14 14:29       ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a4b42b2a-4286-5036-a66b-0ba100320503@6wind.com \
    --to=pascal.mazon@6wind.com \
    --cc=dev@dpdk.org \
    --cc=olgas@mellanox.com \
    --cc=ophirmu@mellanox.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).