From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10064.outbound.protection.outlook.com [40.107.1.64]) by dpdk.org (Postfix) with ESMTP id C9A1DCFC6 for ; Mon, 16 Apr 2018 19:32:45 +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=dEmrC/EgQ41SLhPjXRyn1ZMFwaux2IG7kxG7sp/T9dQ=; b=GGzDD3Gbk+PNXwfnTUa/RbaxhGZBUYkoqKuQMDnr/TfHQAI1hhH3NQkyuAvJXwMuhSxsSHuHRcFF02rG431Vchcm6BxfT1/eQmzugoHcUW+V2veyg7Lo4rRUZOOoxt+Mk9w2F41NQLLVaSyBD3fxPVcJIK5Gup49hJ8Ms4rU/uk= Received: from AM4PR0501MB2657.eurprd05.prod.outlook.com (10.172.215.19) by AM4PR0501MB2289.eurprd05.prod.outlook.com (10.165.82.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.14; Mon, 16 Apr 2018 17:32:44 +0000 Received: from AM4PR0501MB2657.eurprd05.prod.outlook.com ([fe80::6885:c169:afcb:37e6]) by AM4PR0501MB2657.eurprd05.prod.outlook.com ([fe80::6885:c169:afcb:37e6%9]) with mapi id 15.20.0675.015; Mon, 16 Apr 2018 17:32:44 +0000 From: Matan Azrad To: Stephen Hemminger CC: Bruce Richardson , "Burakov, Anatoly" , Thomas Monjalon , "dev@dpdk.org" , "pmatilai@redhat.com" , "david.marchand@6wind.com" , "jia.guo@intel.com" , "konstantin.ananyev@intel.com" , "fbl@redhat.com" Thread-Topic: kernel binding of devices + hotplug Thread-Index: AQHT00ThIlNWXyeugUC+Eesfo2Tt3qP+5c0AgAAQxACAAasfUIACcoSAgAAcrMCAAHCQgIAAANgAgAAFDwCAAAB54A== Date: Mon, 16 Apr 2018 17:32:44 +0000 Message-ID: References: <2407757.yEAnF6RcS7@xps> <20180413164046.GD37024@bricha3-MOBL.ger.corp.intel.com> <20180416083153.GA50020@bricha3-MOBL.ger.corp.intel.com> <20180416095723.0d7698c7@xeon-e3> <20180416101830.0a78c430@xeon-e3> In-Reply-To: <20180416101830.0a78c430@xeon-e3> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0501MB2289; 7:MdD8r+MH2fLmHjgfjO3FIb7wIrvpjObi5kEMJbitfKxxTM+mOpEiCE9ks+2U3mHxCMn1qzS2x+24HNovr2VCYWngLDCp0g3k7GQNh/dwLaKxAscaXvbSfGI7lugSniFKdkrcZ+MmA05V2Kpt4loH5JSM5BabDIZd7fg9Uz2lw2/s3IxL20NqbL4j7z7l+PINfsUv1xQY6PhZODPDnXHe+MjeaEbKBjt4nJOcQVCoC73YwJE9ccHYF9WQae1fTPZb 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:AM4PR0501MB2289; x-ms-traffictypediagnostic: AM4PR0501MB2289: authentication-results: spf=none (sender IP is ) smtp.mailfrom=matan@mellanox.com; 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)(10201501046)(3231232)(944501327)(52105095)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR0501MB2289; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0501MB2289; x-forefront-prvs: 0644578634 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(376002)(366004)(39860400002)(346002)(51444003)(189003)(199004)(81166006)(81156014)(3280700002)(305945005)(316002)(7416002)(86362001)(8676002)(7736002)(186003)(4326008)(26005)(446003)(476003)(74316002)(25786009)(3660700001)(93886005)(6916009)(11346002)(66066001)(9686003)(55016002)(6436002)(7696005)(53936002)(8936002)(99286004)(14454004)(6246003)(33656002)(59450400001)(76176011)(106356001)(478600001)(486006)(102836004)(105586002)(2900100001)(5660300001)(5250100002)(229853002)(2906002)(54906003)(6506007)(97736004)(68736007)(6116002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0501MB2289; H:AM4PR0501MB2657.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: oT3A6u521nKtFqq4wwjjc3vUkGcd0c81QTM+oI+hmRqBtfNGJyVBXkpEsR+sZzHE1cBebiX0PHVD6wKnql9iD2ZAi13l96JyjJIqyT4nK6NpytJTisTOYTGgqmJCuzFSNH+FOngk5iY6cfeTp5U7QAX2v15CJbT/EtqYXTSunUsvoC1I1iwDwv+6G5wTzYAu spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 24a3ca1b-3bcd-41b6-2329-08d5a3c01023 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 24a3ca1b-3bcd-41b6-2329-08d5a3c01023 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2018 17:32:44.1278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0501MB2289 Subject: Re: [dpdk-dev] kernel binding of devices + hotplug 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, 16 Apr 2018 17:32:46 -0000 Hi Stephen From: Stephen Hemminger, Monday, April 16, 2018 8:19 PM > On Mon, 16 Apr 2018 17:10:09 +0000 > Matan Azrad wrote: >=20 > > Hi Stephen > > > > From: Stephen Hemminger, Monday, April 16, 2018 7:57 PM > > > On Mon, 16 Apr 2018 16:11:12 +0000 > > > Matan Azrad wrote: > > > > > > > > If the device management is only managed in one place, i.e. not > > > > > in DPDK, then there is no conflict to manage. > > > > > > > > I can't agree with this statement, The essence of DPDK is to give > > > > a good alternative to managing network devices, DPDK actually > > > > takes a lot of management area to manage by itself to do the user > > > > life better :) > > > > > > More is not better! DPDK is poorly integrated into Linux overall > > > system. Doing more in DPDK makes this worse not better. > > > > In this case I think that yes, more is better. > > Please explain why do you think that in this case it is worse. >=20 > DPDK should work with udev, not try and replace functionality that is alr= eady > done by udev and systemd. Having a parallel and different model makes lif= e > harder for users. This is the same model of the user: The user knows what DPDK does regarding to binding so he just takes it into= account. The same as he knows that the device is used by the DPDK and take= it into account. >=20 > > > > > Buried under this discussion is the fact that the Mellanox > > > bifurcated driver behaves completely differently from every other > > > driver. This makes coming to a common solution much harder. The > > > bifurcated model has advantages and disadvantages, in this case it > > > is a disadvantage since it is not easy to manage usage when it is a s= hared > resource. > > > > Sorry, what is your point? >=20 > The bifurcated model does not play well with driverctl. It just works > differently than other drivers. The bifurcated model works better for sim= ple > case of shared device on bare metal; but it is harder for the transparent > bonding model used on Azure. The eth device is not really available for d= irect > use in kernel; and there is discussion in netdev about hiding it as well = which > will break more things here. And? How it is relevant to the binding discussion?=20