From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0069.outbound.protection.outlook.com [104.47.2.69]) by dpdk.org (Postfix) with ESMTP id 735D82C12 for ; Mon, 23 Apr 2018 11:58:35 +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=LoWOpPQdTZCp5XHuluzkyeoPnjSM9tt5xWtV1v56/Z4=; b=iMBelELHmm2yXf0jGb3N/z9gFUQvoSsIZ5spLS+HaeA1YOWilZbimsv1EeFFRCGqeVFHMUv6TmojvoiOEgsRzYjnZ+qZqit8SfMlX21hdC9qL3WOKGQf+PJeT5F2eeoCrfmdsPoPHUW+UfT9MYTXhy4c3uB4rkPAhOdJT/40j74= Received: from DB7PR05MB4426.eurprd05.prod.outlook.com (52.134.109.15) by DB7PR05MB4140.eurprd05.prod.outlook.com (52.134.107.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.14; Mon, 23 Apr 2018 09:58:34 +0000 Received: from DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::f116:5be4:ba29:fed8]) by DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::f116:5be4:ba29:fed8%13]) with mapi id 15.20.0696.017; Mon, 23 Apr 2018 09:58:34 +0000 From: Shahaf Shuler To: =?iso-8859-1?Q?N=E9lio_Laranjeiro?= CC: "dev@dpdk.org" , Yongseok Koh , "Adrien Mazarguil" Thread-Topic: [dpdk-dev] [PATCH v2 3/3] net/mlx5: implement multicast add list devop Thread-Index: AQHT2tU6jHGsAu/iikufBPt2HpX0cqQN+BIwgAAexgCAAAaJAA== Date: Mon, 23 Apr 2018 09:58:33 +0000 Message-ID: References: <870d4840cdb872d363d103808f82eb3645fd36b0.1524059312.git.nelio.laranjeiro@6wind.com> <20180423073307.j7m7bdl4yguoikff@laranjeiro-vm.dev.6wind.com> <20180423093420.wgng5yll3s3onwkq@laranjeiro-vm.dev.6wind.com> In-Reply-To: <20180423093420.wgng5yll3s3onwkq@laranjeiro-vm.dev.6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR05MB4140; 7:EI0ASHDEwOMtqa5Ixv/JJ5PfixnU4ErbLNtzaPKyfV+gEcteYN2R/iliB8q02kBQvkjMP9gYt8BeRhCB94goUQEkj3hMHhk/CH0OURcQsCxsImLxEpiSl9FiUJ/NwZF5QTMZPtcJhNOwrVLJzZgEKRf/Tu8LtzUznK0EheDUuuXeJkvbnRCm1hV5kCq4IjCtHo+InVFS6drxR0tdKqvTOy/E/hcMoyw/FAwmKVxumOuOpxvHXr/UkrK+YY8Flvdw x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB7PR05MB4140; x-ms-traffictypediagnostic: DB7PR05MB4140: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231232)(944501410)(52105095)(3002001)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DB7PR05MB4140; BCL:0; PCL:0; RULEID:; SRVR:DB7PR05MB4140; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(39380400002)(396003)(346002)(376002)(93886005)(6916009)(33656002)(74316002)(4326008)(2906002)(81166006)(2900100001)(6246003)(5250100002)(66066001)(8676002)(7736002)(305945005)(478600001)(25786009)(8936002)(5660300001)(6506007)(59450400001)(3660700001)(53936002)(316002)(54906003)(102836004)(3280700002)(3846002)(6116002)(86362001)(476003)(6436002)(26005)(7696005)(186003)(76176011)(55016002)(229853002)(9686003)(11346002)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR05MB4140; H:DB7PR05MB4426.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: jGPWc06iIf+VSVaPrFz5DwDcB0WE71Eidagwps3UdjB+4XMGm9jdSU62tpaoF0XxKZwwH3bq4E6qOTIMsxqupHZEF2jxU1B2OZbUEIvzL9La24XMDcH1bikPHFd9x/p6sbw981E2wAcUcbKGFfar3WiXv46uMnkyKrh8tWx7MikcAGKbtd93EMvfokUOP43X spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 01bc25d8-2a4a-4990-4414-08d5a900c6a6 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01bc25d8-2a4a-4990-4414-08d5a900c6a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2018 09:58:33.9578 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR05MB4140 Subject: Re: [dpdk-dev] [PATCH v2 3/3] net/mlx5: implement multicast add list devop 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, 23 Apr 2018 09:58:36 -0000 Monday, April 23, 2018 12:34 PM, N=E9lio Laranjeiro: > Subject: Re: [dpdk-dev] [PATCH v2 3/3] net/mlx5: implement multicast add > list devop >=20 > On Mon, Apr 23, 2018 at 07:57:36AM +0000, Shahaf Shuler wrote: > > Monday, April 23, 2018 10:33 AM, N=E9lio Laranjeiro: > > [...] > > > > > +/** > > > > > + * DPDK callback to set multicast addresses list. > > > > > + * > > > > > + * @param dev > > > > > + * Pointer to Ethernet device structure. > > > > > + * @param mac_addr_set > > > > > + * Multicast MAC address pointer array. > > > > > + * @param nb_mac_addr > > > > > + * Number of entries in the array. > > > > > + * > > > > > + * @return > > > > > + * 0 on success, a negative errno value otherwise and rte_errn= o is > set. > > > > > + */ > > > > > +int > > > > > +mlx5_set_mc_addr_list(struct rte_eth_dev *dev, > > > > > + struct ether_addr *mc_addr_set, uint32_t > nb_mc_addr) { > > > > > + uint32_t i; > > > > > + int ret; > > > > > + > > > > > > > > We should check nb_mc_addr < MLX5_MAX_MC_MAC_ADDRESSES > > > before we start > > > > operate. > > > > > > This verification is done in the sub function. > > > > I see only assert. Did I missed anything? >=20 > No. >=20 > > > Considering an application calling such API wants to remove/replace > > > the old list with new entries. > > > That this new one can be just an addition or totally different list > > > or even empty. > > > This new list can be larger than the amount of MAC addresses the PMD > > > can support. > > > > > > There are two possibilities: > > > > > > 1. The list is too large: the application will enable the all > > > multicast mode to receive the extra mac addresses it needs. > > > > How can application know the size of the MC list? > > only the UC size is being reported: > > info->max_mac_addrs =3D MLX5_MAX_UC_MAC_ADDRESSES >=20 > Such information is not reported at all. The application has to guess. >=20 > > > 2. The list fits (or empty): no issues. > > > > > > At the end the application can also call this API with an empty list > > > to clear it before/after enabling the "all multicast" mode. > > > The final result being the same, does it worse to add a duplicated > > > verification? > > > > At the current code if the list is too large and the PMD was compiled > > w/o debug mode it will results in seg fault. >=20 > Right it needs a verification. >=20 > > > Note: if an error happens the new list is not committed yet i.e. the > > > traffic remains untouched. > > > > > > > > + for (i =3D MLX5_MAX_UC_MAC_ADDRESSES; i !=3D > > > > > MLX5_MAX_MAC_ADDRESSES; ++i) > > > > > + mlx5_internal_mac_addr_remove(dev, i); > > > > > + i =3D MLX5_MAX_UC_MAC_ADDRESSES; > > > > > + while (nb_mc_addr--) { > > > > > > > > Maybe worth checking is_multicast_ether_addr(mc_addr_set) and to > > > > skip > > > > + warn if it is not. > > > > > > Such verification should be done in the public API i.e. ethdev. > > > > I don't understand. > > In the first patch of the series you add extra verification to check > > the mac address validity. >=20 > It only verify the MAC address is not zero, it does not verify the MAC ad= dress > is valid in the function context (e.g. unicast in mlx5_mac_addr_add()). >=20 > > But for the MC you claim it should be done on ethdev layer. >=20 > Dito. >=20 > > It should be consistant. Either ethdev verify the MAC address or the > > PMD. If the first one, then there is no need to add the > > is_zero_ether_addr check on the first patch. >=20 > It is consistent, the PMD only verify the MAC address is not zero and thi= s in > both API. OK, Then I wait for the next version for merge.=20 >=20 > > > > > + ret =3D mlx5_internal_mac_addr_add(dev, > mc_addr_set++, > > > > > i++); > > > > > + if (ret) > > > > > + return ret; > > > > > + } > > > > > + if (!dev->data->promiscuous) > > > > > + return mlx5_traffic_restart(dev); > > > > > + return 0; > > > > > +} > > > > > -- > > > > > 2.17.0 >=20 > Regards, >=20 > -- > N=E9lio Laranjeiro > 6WIND