From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0059.outbound.protection.outlook.com [104.47.2.59]) by dpdk.org (Postfix) with ESMTP id 26D6C2BE5 for ; Tue, 10 Jul 2018 13:15:31 +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:X-MS-Exchange-SenderADCheck; bh=OWaYBz2juyI5Zcf9lrpcaad54CQ5X9tfwTuEoAXKPlk=; b=IzmroSb/LROJuq6qA3KjpaYJiMaKies1/X/gFglwp/SrH9mPmDbBPIRTBg40F3qxMJblWFkKIguXlH2gHUlp74Veo1CHO7hrAHargh3dcHhyTl/gwZfb9TVXl2Y5AJCaRhQaVnn4PqoMLH07pfDUPhoRFffA36pXIEStzvfg+5k= Received: from DB7PR05MB4426.eurprd05.prod.outlook.com (52.134.109.15) by DB7PR05MB4937.eurprd05.prod.outlook.com (20.176.235.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.21; Tue, 10 Jul 2018 11:15:30 +0000 Received: from DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::d9c6:913c:c361:f7b7]) by DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::d9c6:913c:c361:f7b7%6]) with mapi id 15.20.0930.022; Tue, 10 Jul 2018 11:15:30 +0000 From: Shahaf Shuler To: Adrien Mazarguil CC: "dev@dpdk.org" Thread-Topic: [PATCH v4 09/10] net/mlx5: add parameter for port representors Thread-Index: AQHUFDyZ2IKBe6YD0kukdLKGlR6zcaSGzo+ggAFsLYCAAAqtMIAAC/SAgAAEoAA= Date: Tue, 10 Jul 2018 11:15:29 +0000 Message-ID: References: <20180704172322.22571-1-adrien.mazarguil@6wind.com> <20180705083934.5535-1-adrien.mazarguil@6wind.com> <20180705083934.5535-10-adrien.mazarguil@6wind.com> <20180710093723.GI5211@6wind.com> <20180710105823.GM5211@6wind.com> In-Reply-To: <20180710105823.GM5211@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=shahafs@mellanox.com; x-originating-ip: [31.154.10.105] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR05MB4937; 7:VPSixccklI/F9Vuw2DEtaMMmYGdjnO/8o5M2a7SL288r54Pjb3MU9f2Vq/HEErczJVMavhjFELEmaiw14wsnCZ2BrBsiEQ7B0zG91OGSgUefEphzdnNipqZXN8Y4Q0kKHHdayx8V7Lm+0lMl3VOcdM+shfAn64JsliP6kwWXpBkDNAVxPqAvnakMGRbdfjnQc/lT11naGFgByg7ISQi0Mgqu7RKu57DsCOgqVcq6+R/1Fgz4hlqbL5nlIWeldPCf x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 88302a37-b69f-467c-1575-08d5e656723d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DB7PR05MB4937; x-ms-traffictypediagnostic: DB7PR05MB4937: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:DB7PR05MB4937; BCL:0; PCL:0; RULEID:; SRVR:DB7PR05MB4937; x-forefront-prvs: 0729050452 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(136003)(376002)(366004)(199004)(189003)(6436002)(6506007)(7736002)(76176011)(14454004)(305945005)(7696005)(11346002)(106356001)(25786009)(68736007)(4326008)(446003)(486006)(102836004)(105586002)(6916009)(55016002)(2900100001)(81166006)(26005)(478600001)(33656002)(81156014)(8676002)(74316002)(9686003)(476003)(99286004)(8936002)(186003)(66066001)(256004)(93886005)(53936002)(86362001)(5660300001)(6246003)(3846002)(97736004)(229853002)(5250100002)(316002)(6116002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR05MB4937; H:DB7PR05MB4426.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LbhAgMfu/WlGctCWD/b7ywQ03qu9FliC/EKdVpxo3ldseBCo8wSdMK2NtD6y8bDV6UyaK5MLtXZ1Gf6+75mKXFkhTlcGsHCBC16XNR+cb97skMF3/dzUPDn6Yw2sqQwfic05XFVxojkZSGc6JsuNNBv415tkw06bEALTxn6SoYiXz2/7AyGhGeRHOuAXhP1oXWpBlpUqX8+fVZewkYX+Gv/Ep9VgWII5xY+fQrXXUBni/oAKg8aMKTbwwE4yOWUD0W9LTqo8ROLbObA38pzTVMbcmajgVJ0X0809SvyBhqjwCLdUHEKLTHsg57FEQ5RnF+GmuK4EB+1RRFCPQRzdXECV9MbVjVwV+DIY0c+ss4s= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 88302a37-b69f-467c-1575-08d5e656723d X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2018 11:15:29.9744 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR05MB4937 Subject: Re: [dpdk-dev] [PATCH v4 09/10] net/mlx5: add parameter for port representors 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: Tue, 10 Jul 2018 11:15:31 -0000 Tuesday, July 10, 2018 1:58 PM, Adrien Mazarguil: > Subject: Re: [PATCH v4 09/10] net/mlx5: add parameter for port > representors >=20 > On Tue, Jul 10, 2018 at 10:16:03AM +0000, Shahaf Shuler wrote: > > Tuesday, July 10, 2018 12:37 PM, Adrien Mazarguil: > > > Subject: Re: [PATCH v4 09/10] net/mlx5: add parameter for port > > > representors > > > > > > On Mon, Jul 09, 2018 at 11:57:37AM +0000, Shahaf Shuler wrote: > > > > Thursday, July 5, 2018 11:46 AM, Adrien Mazarguil: > > > > > Subject: [PATCH v4 09/10] net/mlx5: add parameter for port > > > > > representors > > > > > > > > > > Prior to this patch, all port representors detected on a given > > > > > device were probed and Ethernet devices instantiated for each of > them. > > > > > > > > > > This patch adds support for the standard "representor" > > > > > parameter, which implies that port representors are not probed > > > > > by default anymore, except for the list provided through device > arguments. > > > > > > > > > > (Patch based on prior work from Yuanhan Liu) > > > > > > > > > > Signed-off-by: Adrien Mazarguil > > > > > Reviewed-by: Xueming Li > > > > > -- > > > > > v3 changes: > > > > > > > > > > - Adapted representor detection to the reworked > mlx5_dev_spawn(). > > > > > > > > @@ -672,7 +679,9 @@ mlx5_uar_init_secondary(struct rte_eth_dev > > > *dev) > > > > > * > > > > > * @return > > > > > * A valid Ethernet device object on success, NULL otherwise a= nd > > > rte_errno > > > > > - * is set. > > > > > + * is set. The following error is defined: > > > > > + * > > > > > + * EBUSY: device is not supposed to be spawned. > > > > > */ > > > > > static struct rte_eth_dev * > > > > > mlx5_dev_spawn(struct rte_device *dpdk_dev, @@ -723,6 +732,26 > > > > > @@ mlx5_dev_spawn(struct rte_device *dpdk_dev, > > > > > int own_domain_id =3D 0; > > > > > unsigned int i; > > > > > > > > > > + /* Determine if this port representor is supposed to be > spawned. */ > > > > > + if (switch_info->representor && dpdk_dev->devargs) { > > > > > + struct rte_eth_devargs eth_da; > > > > > + > > > > > + err =3D rte_eth_devargs_parse(dpdk_dev->devargs- > >args, > > > > > ð_da); > > > > > + if (err) { > > > > > + rte_errno =3D -err; > > > > > + DRV_LOG(ERR, "failed to process device > arguments: > > > > > %s", > > > > > + strerror(rte_errno)); > > > > > + return NULL; > > > > > + } > > > > > + for (i =3D 0; i < eth_da.nb_representor_ports; ++i) > > > > > + if (eth_da.representor_ports[i] =3D=3D > > > > > + (uint16_t)switch_info->port_name) > > > > > + break; > > > > > + if (i =3D=3D eth_da.nb_representor_ports) { > > > > > + rte_errno =3D EBUSY; > > > > > > > > Why EBUSY is the correct errno? Will another attempts to probe the > > > > device > > > can be successful? > > > > > > That's the definition of EAGAIN :) > > > > > > I thought EBUSY in the sense of "don't disturb" would be > > > appropriate. This value was also chosen because it is not likely to > > > be returned by any intermediate function calls. I've defined EBUSY > > > along with the return value of this function for clarity (see above).= Any > suggestion? > > > > How about ENODEV ? >=20 > Already used by many internal functions, typically returned if the associ= ated > netdevice doesn't exist (e.g. sent to another netns; a fatal error when > probing representors). >=20 > We need a unique error code that says "OK, no problem, just not this one"= . OK, we can keep the EBUSY.=20 >=20 > -- > Adrien Mazarguil > 6WIND