From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20045.outbound.protection.outlook.com [40.107.2.45]) by dpdk.org (Postfix) with ESMTP id D92292BCE for ; Mon, 23 Apr 2018 09:57:37 +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=71tgelP5EJyjhZ+gJmgrPJYz9ICNra4X7+fgoGr9RIo=; b=KBibZ8lj/g3CZD+kKPUOKZxl3aE8U6xxbuuesCGu085i5R3rBjY4xSSoiF6XmcFEkV1aVrqeiDgkD4l3rCEgLH6xffz/1chTmv0VF8VUE9dEQuhe4HMFG36Ybuxgw7vn0iXmH7xrsycfaiXmxBjelYB/LJGJl/V5rQWrUMJ9I3c= Received: from DB7PR05MB4426.eurprd05.prod.outlook.com (52.134.109.15) by DB7PR05MB4185.eurprd05.prod.outlook.com (52.134.107.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.12; Mon, 23 Apr 2018 07:57:36 +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 07:57:36 +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+BIw Date: Mon, 23 Apr 2018 07:57:36 +0000 Message-ID: References: <870d4840cdb872d363d103808f82eb3645fd36b0.1524059312.git.nelio.laranjeiro@6wind.com> <20180423073307.j7m7bdl4yguoikff@laranjeiro-vm.dev.6wind.com> In-Reply-To: <20180423073307.j7m7bdl4yguoikff@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; DB7PR05MB4185; 7:Dfo3/SOA76Br6T+gF7PsP2y4NzAOz412SXesAasXOO0AK7C3xfd4IGMyljvZXfRDfMHBYrmminLnFReBbccDcvsDeDuxxnZtFfcR8FnajPbDcGphY1DogQydLXpkB+mZyjFlC7eMMOQXE4iZh6hYlnJH535WDjhfiBzYYYpnpiRC+QvXB5OQ3L+vS1Pk6YDGBmdw0rAq0XlngV4gUioWDLwJrg4v2mZPu+sD4YircEyyvgohz+EqY29hb2m59Znj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB7PR05MB4185; x-ms-traffictypediagnostic: DB7PR05MB4185: 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)(3002001)(93006095)(93001095)(10201501046)(3231232)(944501410)(52105095)(6055026)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:DB7PR05MB4185; BCL:0; PCL:0; RULEID:; SRVR:DB7PR05MB4185; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(39380400002)(396003)(366004)(6246003)(4326008)(9686003)(55016002)(53936002)(33656002)(11346002)(446003)(186003)(476003)(7696005)(26005)(102836004)(59450400001)(76176011)(6916009)(6506007)(3280700002)(6436002)(66066001)(93886005)(54906003)(305945005)(86362001)(25786009)(316002)(3846002)(74316002)(6116002)(7736002)(2906002)(5250100002)(3660700001)(8936002)(2900100001)(8676002)(478600001)(5660300001)(81166006)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR05MB4185; H:DB7PR05MB4426.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: bEza6uGtmxp0WSyZaJ1h9Ma2bVMYH8WTF72leZYhNbityzze9EgcZXbWkY7XT1T4G2k/0ImKSGqm9iE/7n9gRB7PKU+y0XL2/DpP5jbFA7sR8uIE9fo+9dW3q90f52Ot1HwWwN/olRpn60yJGX3dk3WLhLA7lgr+6XWcuw0/F2wvxdLv9lhof/qHtjB8cJpk 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: cc48945e-7d3d-422f-cd88-08d5a8efe0b9 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: cc48945e-7d3d-422f-cd88-08d5a8efe0b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2018 07:57:36.2310 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR05MB4185 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 07:57:38 -0000 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_errno 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. >=20 > This verification is done in the sub function. I see only assert. Did I missed anything?=20 >=20 > Considering an application calling such API wants to remove/replace the o= ld > list with new entries. > That this new one can be just an addition or totally different list or ev= en > empty. > This new list can be larger than the amount of MAC addresses the PMD can > support. >=20 > There are two possibilities: >=20 > 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 > 2. The list fits (or empty): no issues. >=20 > At the end the application can also call this API with an empty list to c= lear 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 d= ebug mode it will results in seg fault.=20 >=20 > Note: if an error happens the new list is not committed yet i.e. the traf= fic > remains untouched. >=20 > > > + 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. >=20 > Such verification should be done in the public API i.e. ethdev. I don't understand.=20 In the first patch of the series you add extra verification to check the ma= c address validity. But for the MC you claim it should be done on ethdev la= yer.=20 It should be consistant. Either ethdev verify the MAC address or the PMD. I= f the first one, then there is no need to add the is_zero_ether_addr check = on the first patch.=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