From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 07D9F2B83; Tue, 15 May 2018 00:18:07 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2018 15:18:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,401,1520924400"; d="scan'208";a="55168256" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga001.fm.intel.com with ESMTP; 14 May 2018 15:18:05 -0700 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 14 May 2018 15:18:05 -0700 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.235]) by FMSMSX114.amr.corp.intel.com ([10.18.116.8]) with mapi id 14.03.0319.002; Mon, 14 May 2018 15:18:05 -0700 From: "Wiles, Keith" To: Ophir Munk CC: DPDK , Pascal Mazon , "Thomas Monjalon" , Olga Shern , "Shahaf Shuler" , "stable@dpdk.org" Thread-Topic: [PATCH v2] net/tap: fix isolation mode toggling Thread-Index: AQHT69CmU8ODmypzeUaRkilE2fxC16QwQJGA Date: Mon, 14 May 2018 22:18:05 +0000 Message-ID: <46ECD048-C95D-4F8B-B73F-7FD299B48394@intel.com> References: <1525682200-21821-1-git-send-email-ophirmu@mellanox.com> <1526335915-27693-1-git-send-email-ophirmu@mellanox.com> In-Reply-To: <1526335915-27693-1-git-send-email-ophirmu@mellanox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.16.78] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2] net/tap: fix isolation mode toggling X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 22:18:08 -0000 > On May 14, 2018, at 5:11 PM, Ophir Munk wrote: >=20 > Running testpmd command "flow isolae 0" (i.e. disabling flow > isolation) followed by command "flow isolate 1" (i.e. enabling > flow isolation) may result in a TAP error: > PMD: Kernel refused TC filter rule creation (17): File exists >=20 > Root cause analysis: when disabling flow isolation we keep the local > rule to redirect packets on TX (TAP_REMOTE_TX index) while we add it > again when enabling flow isolation. As a result this rule is added > two times in a row which results in "File exists" error. > The fix is to identify the "File exists" error and silently ignore it. >=20 > Another issue occurs when enabling isolation mode several times in a > raw in which case the same tc rules are added consecutively and > rte_flow structs are added to a linked list before removing the > previous rte_flow structs. > The fix is to act upon isolation mode command only when there is a > change from "0" to "1" (or vice versa). >=20 > Fixes: f503d2694825 ("net/tap: support flow API isolated mode") > Cc: stable@dpdk.org >=20 > Reviewed-by: Raslan Darawsheh > Signed-off-by: Ophir Munk > --- > v1: > initial release > v2: > 1. Updates based on Keith Wiles review > 2. Do not empty list of implicit TC rules (role back to legacy implementa= tion) > to ensure TC implicit rules cleanup during implicit rules flushing >=20 > drivers/net/tap/tap_flow.c | 24 ++++++++++++++---------- > 1 file changed, 14 insertions(+), 10 deletions(-) >=20 > diff --git a/drivers/net/tap/tap_flow.c b/drivers/net/tap/tap_flow.c > index aab9eef..6b60e6d 100644 > --- a/drivers/net/tap/tap_flow.c > +++ b/drivers/net/tap/tap_flow.c > @@ -1568,10 +1568,14 @@ tap_flow_isolate(struct rte_eth_dev *dev, > { > struct pmd_internals *pmd =3D dev->data->dev_private; >=20 > + /* normalize 'set' variable to contain 0 or 1 values */ > if (set) > - pmd->flow_isolate =3D 1; > - else > - pmd->flow_isolate =3D 0; > + set =3D 1; > + /* if already in the right isolation mode - nothing to do */ > + if ((set ^ pmd->flow_isolate) =3D=3D 0) > + return 0; > + /* mark the isolation mode for tap_flow_implicit_create() */ > + pmd->flow_isolate =3D set; > /* > * If netdevice is there, setup appropriate flow rules immediately. > * Otherwise it will be set when bringing up the netdevice (tun_alloc). > @@ -1579,20 +1583,20 @@ tap_flow_isolate(struct rte_eth_dev *dev, > if (!pmd->rxq[0].fd) > return 0; > if (set) { > - struct rte_flow *flow; > + struct rte_flow *remote_flow; >=20 > while (1) { > - flow =3D LIST_FIRST(&pmd->implicit_flows); > - if (!flow) > + remote_flow =3D LIST_FIRST(&pmd->implicit_flows); > + if (!remote_flow) > break; > /* > * Remove all implicit rules on the remote. > * Keep the local rule to redirect packets on TX. > * Keep also the last implicit local rule: ISOLATE. > */ > - if (flow->msg.t.tcm_ifindex =3D=3D pmd->if_index) > + if (remote_flow->msg.t.tcm_ifindex =3D=3D pmd->if_index) > break; > - if (tap_flow_destroy_pmd(pmd, flow, NULL) < 0) > + if (tap_flow_destroy_pmd(pmd, remote_flow, NULL) < 0) > goto error; > } > /* Switch the TC rule according to pmd->flow_isolate */ > @@ -1739,8 +1743,8 @@ int tap_flow_implicit_create(struct pmd_internals *= pmd, > } > err =3D tap_nl_recv_ack(pmd->nlsk_fd); > if (err < 0) { > - /* Silently ignore re-entering remote promiscuous rule */ > - if (errno =3D=3D EEXIST && idx =3D=3D TAP_REMOTE_PROMISC) > + /* Silently ignore re-entering existing rule */ > + if (errno =3D=3D EEXIST) > goto success; > TAP_LOG(ERR, > "Kernel refused TC filter rule creation (%d): %s", > --=20 > 2.7.4 >=20 Looks good. Acked By: Keith Wiles Regards, Keith