From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0053.outbound.protection.outlook.com [104.47.0.53]) by dpdk.org (Postfix) with ESMTP id 53FF62BF7 for ; Wed, 28 Mar 2018 07:56:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bwFBJ2QNntOnt4TRTbo5j3zCW6erYCZUJ58zBfwxvEE=; b=Zepc1sQ5s0qsBUcB87YOVMhzgXCrbyaax8KTQ3dK4eVL1Tn+V8YSMMuAVh/vrHgllhRYVgrxDsRCewRx5ylvTl0VPlKLJ0RheBMuIyFux6gETonZWuZlV/tRUfQ1Dx1V/rYzDs8avx9NlfSrpJcHqgdP6iOerI+JDJsh1Zcwqc8= Received: from DB7PR05MB4426.eurprd05.prod.outlook.com (52.134.109.15) by DB7PR05MB4267.eurprd05.prod.outlook.com (52.134.108.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.12; Wed, 28 Mar 2018 05:56:51 +0000 Received: from DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::808d:386e:26f3:859f]) by DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::808d:386e:26f3:859f%13]) with mapi id 15.20.0609.012; Wed, 28 Mar 2018 05:56:51 +0000 From: Shahaf Shuler To: =?iso-8859-1?Q?N=E9lio_Laranjeiro?= CC: Adrien Mazarguil , Yongseok Koh , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v3 1/3] net/mlx5: use Netlink to add/remove MAC addresses Thread-Index: AQHTwbzxtVGv2H+d90GeoBi5DhkLaaPcAHZwgAANGgCACSFAcA== Date: Wed, 28 Mar 2018 05:56:51 +0000 Message-ID: References: <20180322090445.63pcs6jwljdob6pi@laranjeiro-vm.dev.6wind.com> <20180322102830.x7rdaywq7t3c36ma@laranjeiro-vm.dev.6wind.com> In-Reply-To: <20180322102830.x7rdaywq7t3c36ma@laranjeiro-vm.dev.6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.154.10.107] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR05MB4267; 7:pxlLiNQPeWcN4rVYnC8iJUgBhJfnJzn8BcMxKO2HWlATIPSw/xGeIe7I2mjXPw/YIP80fOkE16kyh5+Gt8vIJ7mwu5sAICn/7hq8AU4t2AuDA0aUGwuhjPD4sBgU+yNtP1OqSlEg3TibOCIE9ge9PgfOJ5wLXNr7gMJlw+dpN7uhYgKjGYVeGBa/zkT2TaGVRlBfSg4WHyAx9B0LksaKhJDximmQXCyAy0sHZ2R305LNF5p1PYihHu3NSAfb4NGs x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8e0fa0ca-d403-44ff-ac74-08d59470b3aa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB7PR05MB4267; x-ms-traffictypediagnostic: DB7PR05MB4267: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DB7PR05MB4267; BCL:0; PCL:0; RULEID:; SRVR:DB7PR05MB4267; x-forefront-prvs: 06259BA5A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(366004)(346002)(39860400002)(39380400002)(189003)(199004)(76104003)(5660300001)(4326008)(99286004)(316002)(2900100001)(54906003)(478600001)(7736002)(6916009)(33656002)(229853002)(6246003)(93886005)(25786009)(74316002)(305945005)(6506007)(66066001)(5250100002)(53936002)(76176011)(11346002)(486005)(486005)(476003)(446003)(6346003)(26005)(102836004)(81156014)(105586002)(186003)(2906002)(14454004)(68736007)(3280700002)(3660700001)(3846002)(6116002)(7696005)(8936002)(81166006)(86362001)(8676002)(6436002)(55016002)(9686003)(106356001)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR05MB4267; H:DB7PR05MB4426.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=shahafs@mellanox.com; x-microsoft-antispam-message-info: 1ptMlBeZxk6zlKkx9vrKjVjlMI9gj/XjB9Zrkwc4VO6Dle6NFml0kYvQ4PYms7xXcGIY2BJ/BMHmFNCWoW2NqcsIPcIm4qfuVupdQyqm1i3dlgWYUuGRZw2/NTkjayjLj8hAXWeEiaU+ja0sneaI93fh5o4aaM6Nq0EBzhUPkjufW2cvcnSrYmCXMfqwE60PduFF2O5YGdCW31nzwNSSaDFnxUFmO1Hq2vq6QxMzUYEILPNeGsPMu5q78N7jbWTohD+b7ef1Zg/6F56zcYAt4kpLsAGp2QlPP6W1WE04nABMBc/ESWv0nvPvrnrXE1PXA+TdCHuH7H0ZfrO9DSDS6w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8e0fa0ca-d403-44ff-ac74-08d59470b3aa X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2018 05:56:51.3098 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR05MB4267 Subject: Re: [dpdk-dev] [PATCH v3 1/3] net/mlx5: use Netlink to add/remove MAC addresses 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: Wed, 28 Mar 2018 05:56:56 -0000 Thursday, March 22, 2018 12:29 PM, N=E9lio Laranjeiro: > On Thu, Mar 22, 2018 at 09:45:16AM +0000, Shahaf Shuler wrote: > > Thursday, March 22, 2018 11:05 AM, N=E9lio Laranjeiro: > > > > What if the DPDK process is terminated ungracefully? I think the > > > > MAC table will remain with all the MACs which were added. > > > > The next run of the process may have un-expected results. > > > > > > > > Should we flush the neighbor mac table also on probe to make sure > > > > only the VF mac exists? > > > > > > In such situation the sysadmin should make the clean up, the DPDK > > > application cannot consider it is the only one using the device as > > > it is not the case, Linux still owns the device. > > > We have no guarantee the admin did not use another MAC address for a > > > service outside of the DPDK application (even if in such case he > > > should disable this feature to fully control what happens on the neig= hbor > mac table). > > > > There should be only one owner for the VF mac tables - either the DPDK = or > the Linux. > > > > If the DPDK is the owner, it should do the cleanup. If the sysadmin > > wants to be the owner then it should set the proper flag when running > > dpdk or alternatively not set the VF in trusted mode. >=20 > It is a little more complex than what you think, according to the Linux > configuration the tables will have entries already present or not e.g. > broadcast v6 is present only if the Linux supports the v6 (by compilation= or > configuration). >=20 > For such reason the PMD cannot consider it owns the bridge tables when > acting as a VF, otherwise it needs to trigger any Linux configuration > modification and enable the according functionalities. OK.=20 Then I think a proper documentation is needed as part of this patch in mlx = guide. To explain the application that a cleanup of the neighbor table is needed i= n case the PMD is terminated ungracefully.=20 >=20 > To answer this: > > There should be only one owner for the VF mac tables - either the DPDK = or > the Linux. >=20 > That's right, DPDK application or Linux should own the device, the PMD is > none of the two. It is just a driver. >=20 > Thanks, >=20 > -- > N=E9lio Laranjeiro > 6WIND