From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0050.outbound.protection.outlook.com [104.47.41.50]) by dpdk.org (Postfix) with ESMTP id 197D12C37 for ; Mon, 1 Oct 2018 11:55:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3Nw58Unah21XQ2GhCjyvxQQArZvzHn3c5esTofjh2EI=; b=PGLFEznIo7YflLDnAyUd6bNobCbGLb3N94IxlcGi6Kq3cE8wJiNOp8R2uQX7p9mMBdn3p835Mt6dkWwz5s2OrqhCNloXlbaTnJroF/tyTjNPNJUAqHhIvc08JguQjiyHs8pRd4hzqARMADmG9aZh5W6BfMyV1jTeMskkLNeIXug= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (115.113.156.3) by BYAPR07MB4999.namprd07.prod.outlook.com (2603:10b6:a03:5b::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.25; Mon, 1 Oct 2018 09:55:30 +0000 Date: Mon, 1 Oct 2018 15:25:15 +0530 From: Jerin Jacob To: Stephen Hemminger Cc: Jeff Guo , bruce.richardson@intel.com, ferruh.yigit@intel.com, konstantin.ananyev@intel.com, gaetan.rivet@6wind.com, jingjing.wu@intel.com, thomas@monjalon.net, motih@mellanox.com, matan@mellanox.com, harry.van.haaren@intel.com, qi.z.zhang@intel.com, shaopeng.he@intel.com, bernard.iremonger@intel.com, arybchenko@solarflare.com, wenzhuo.lu@intel.com, anatoly.burakov@intel.com, jblunck@infradead.org, shreyansh.jain@nxp.com, dev@dpdk.org, helin.zhang@intel.com Message-ID: <20181001095513.GA18062@jerin> References: <1498711073-42917-1-git-send-email-jia.guo@intel.com> <1538307003-11836-1-git-send-email-jia.guo@intel.com> <20181001110012.273b38fc@shemminger-XPS-13-9360> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20181001110012.273b38fc@shemminger-XPS-13-9360> User-Agent: Mutt/1.10.1 (2018-07-13) X-Originating-IP: [115.113.156.3] X-ClientProxiedBy: BM1PR0101CA0002.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:18::12) To BYAPR07MB4999.namprd07.prod.outlook.com (2603:10b6:a03:5b::24) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8225a3a1-a848-4efe-8c0c-08d627840bbd X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR07MB4999; X-Microsoft-Exchange-Diagnostics: 1; BYAPR07MB4999; 3:zvWZMHzBew44v/4eKaFAUT2oMXletRP2S89MawCO5vr2zYLksy96dqqSDMFm+NkSUuMKqRP+1z3nzL7ZrNY1XtJ92uuVc4iVbKhiSXDjodZexP6bEITraiIE24nDMl5jIdGoKZluAI+g03qRHsQ0rIuYuz2kX4dE5YJIk6Kx4ZKN3tmswnH/xsHX3rDTbApExgCW67ROjthN3MBB2ITR2OnD/dkYJ5GuRLysIFNZp2dAF9Q3PdYQ57yxP2qxWMWB; 25:n9VLKSL0fbpQ0tFFvO8ftrZt6KC2ocDWnblh6lkz/DSWpnVAY5J+THxuiiioUHDWG2geN1PxEKk+XRkyQJNUSLDvZPgWpvjY67zAa7YYro38YjLsRsr5JgpurxFXNI/dEQZyQZS21aXtkuS5sNY4pCrTyECH4eEbnU8V2A6PpaGixe0Ur2MZDj2gETp/kT4DkgT427PCGhGN60TRz0qfLh7BZ86OSFLVnpY0Ci4VkUJlDqd/GZ704YFz0jRETW28Eqn8Azduhmq+ncUfdHXAdvU2RE37xUfqcrwOB3herKSuS3dwHWw3y/o96hi54v12uDic9fqGGtEl0/j9DbMVBA==; 31:eXnHxAf9mIPUmFv8+D3DlIlU8nDlfugyjOnV/ndjYVvxouyKievGWYqAhDUn94itQWQhMchojsR08L6F9OFgYwmrijfh5jahqNSIv7jMWW4OzdwLUltqxwn8M17VXuDbwxW6CoBrGzpyUIP8PUs0InEr1XfncXAjh+Q6314Mzji9y4BDy9asykl6dVItA4Jlj5ej0jsNvd0S844ATSSU+YwokR0BRCUOCyZIne0NtLo= X-MS-TrafficTypeDiagnostic: BYAPR07MB4999: X-Microsoft-Exchange-Diagnostics: 1; BYAPR07MB4999; 20:R5urq4d6NYMVcnUI3f6zZrgq2L1rAN/cgZfGQZ//t4grWjajLaGNJgZ836cwCCBxOfQqklAOrygLZhFmVWuxnbfC8Y1iyjPuSwgsPRQSgKHwTRArsc6krDLBbpqmkvC5y5U7oienvf/EmY2T0k43VzLG3wG0HpkjwElgtEcYt9nJuZbK6jNd5DzUa6haXNSkqtLYEz8Ndcsiw1Ui6Ee6QxTRhyH9Hd+FFo/i3dOB5pPBHZKYFUSlzQ8DcbTwctpzCusJlRxJWJ/KcV696ep4CoAqBqGwUPqAkv6l1T2txoHBz0QwqdpWh6WiYutMSIh3LdDlb2ugNvS7ABrXKvNsKU51yrxOZGSoJmDPPQxbQjElsHaeGi8RvuP7+LTWuEkwd0Nr/UXo35oB4l6hTdF7DGNytbSZu5WkMBTtr20JP8LMcrsnLxEuzwg9DhKDMNNaWaWGKD6rhScBw/qMtTYcFSYtrKJuTqSqwp2r17mEfLgRMTkfz8Fl5lkJEcrOIEbTwVjBv49P2UF+v+t5kfdE2pqDeYnnIlPGxFXkuJJL0BrmApx+YpxBcxGC5VkI5LTR5GJvYmapw4N+vqGI6usJoKsRQeliZT4p8ITitkLx7s8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(228905959029699)(185117386973197)(192374486261705); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051); SRVR:BYAPR07MB4999; BCL:0; PCL:0; RULEID:; SRVR:BYAPR07MB4999; X-Microsoft-Exchange-Diagnostics: 1; BYAPR07MB4999; 4:tF6sJHhNmfSVDLfuyi1AmOzPV+twk5Uc7OrufZ6pTsV7GPZZBGRfzWj1DgtQJcXzNJtFr/8Ee2H0QP6Ljeyg+1ohOscldJB7SOpsBhe+i0vt+cFbtN6SG7iG6AGZsUAWuMrPg655FNusRiEr9lsrkU/HJKwGXmFdGsMfStfCB+QmCIRjSa2wINyQtyFyoQcgjJ3klQmWttXsijlEVKhuFfptFUiCtLKQqojUMXBM4AMx5tc86wzKgaj2vois1TItiALJo+M2CbBJuT2PsW1wKSzV4B2c7gvPAmEkxhUTc3Joye344s3knhyvki6Bk0pdyxdROZEZTD/Aqd6Q986hD7x+yZi/2EEQ1S5kdOHsFk2mC/mI5IV/Ai9NWDUt/RiA X-Forefront-PRVS: 0812095267 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39860400002)(396003)(136003)(13464003)(189003)(199004)(6666003)(6246003)(34290500001)(4326008)(68736007)(1076002)(33656002)(3846002)(6116002)(25786009)(316002)(8936002)(81156014)(8676002)(50466002)(81166006)(47776003)(66066001)(105586002)(106356001)(72206003)(2870700001)(97736004)(478600001)(16526019)(476003)(186003)(33716001)(446003)(52146003)(2486003)(7736002)(956004)(11346002)(6496006)(386003)(7416002)(58126008)(26005)(486006)(5660300001)(229853002)(2906002)(76176011)(14444005)(55236004)(5024004)(52116002)(6306002)(9686003)(33896004)(55016002)(42882007)(305945005)(44832011)(6916009)(966005)(53936002)(23676004)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR07MB4999; H:jerin; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWUFQUjA3TUI0OTk5OzIzOkNkQTlLeGZqdXMrVjd4K3UwZEdLVFpYamMx?= =?utf-8?B?dWd2TFVLTDNIYjlrWWVibGFCa3krMmU0OW9yQjR1ZEF1Wm1vc2kzYXFwK2FU?= =?utf-8?B?Q1FiVjBuL3c2bVFjYVIzbXhtRHlkSFN2aFdjODM0N0lNVlNuY1llNzdMV0Jz?= =?utf-8?B?WTBlcWdja3JSVFY0VGUzM2xwUGNEdC9SQWxOOVVFcTVUcU1RUnhiL2pDeEZJ?= =?utf-8?B?RDRIckt3dExvVjBwTjJHTDN5cEJxcVhoNXZJRVJRMzU3Wm56SEp2eVJXYVdL?= =?utf-8?B?eUFlQ05NRGpxeUVVT25WREJtTVR4eHJKU3ViMDRMMmFDYTVrSVlaMytYNHo5?= =?utf-8?B?ekp0cGtTVWdCUm1xVDErWG1iZm0zdEFuZDBoSVJSM2t1c2NmMm9VeVliOU5a?= =?utf-8?B?R3ZUK1ptaE1BaUJidzNUTlhWT2w2N2NjSHNQV0k0N3ZIbGlUMjZrbDdGdUI4?= =?utf-8?B?bEpSWk9sb0pGam5PdlM5Zzh6ZUp4MkVubStYOW9QQXo1MC9YQTk1Yk1nVFl2?= =?utf-8?B?RENlYUpYVjJDaG85UTJKQVJIdmJRRWhOTytoN083TnhJMitoVndkK0haS2h0?= =?utf-8?B?VzdrVzd4ZmM2NCtBZ1ZCeDcvQS8vWjFYNnVuaXhnL0l0b1ZqZk4yaDJqZkYx?= =?utf-8?B?OVhDZWJZTEc4YmFURGhaSzBCenVwc29VNGZRSGM5aFZZcDA0N3V4WUdOMGE0?= =?utf-8?B?aGtrQzFHV2doVGF0T0JKekF2Q0lXaDU1dmdWRkhEOVZORDIrWUpqa1liN2lF?= =?utf-8?B?MSs5Z2xPelBHeEtsU3l1Z1R6S0ZORlpFQm11NmZuTUtNOHBSVnNNOXp1NmFQ?= =?utf-8?B?SHVlZ2d2eHRLQ2FBclhDQTNWRmUvRjVLWG0va2NiK0lhUTlhZUQrQk5LVThH?= =?utf-8?B?Q0JEZFMwVjJhK0wyekl4ODRYVE9acGU5ZnRBMnNpZk1qUWwyUGw5cVdFaU9T?= =?utf-8?B?ZGFWempGL0VqU3VuMlozUGZCSmc5NHZlUmwzdkRYQ01RVXpqcnVDVkJ1dFg4?= =?utf-8?B?amIwNkhnQmdnVGxvQ2tPVUU5OHV1eTk2eHN2dHBwWEFQNThZWG1LOHphYXRr?= =?utf-8?B?cENWOUZJYklzN0ZyT01IejkrU3ZFNkR4amRZczlRRWp0RmJBTGNDbHd4V2lB?= =?utf-8?B?Yk1rUnNqbU4yUXlJVm04a2dNN2NUNnFkN1lYbTdLdVVWNnVsT3dFakQ3bDdM?= =?utf-8?B?K2NtZHAzUUZQeHFkYVZ0TCtBSnFxTG5UM0QxWlpjZU9uWDhiZkJkd2ZwNHNk?= =?utf-8?B?MUprRnRwdHBFOGNBK2lBajBFZWFnVGI0M0xUeFJQemhvNWViNWJUK0ZmTVFE?= =?utf-8?B?dHM4VEVZVlZNd2E1U0c0ZkV2MnlpYUtLUWxndVJpVmFnQjhGSlJBTmVRRmRY?= =?utf-8?B?WFMweVBEWWhJaFc5ZE03R3pxcHRIak40RnNYeUpJN0UwVmg1Y2xRT20vQS9o?= =?utf-8?B?NW5YK2pWV3FPTkFrbUw1N1pJeDREZ3hxaVI1SzFac0N0aFJyYWNBY0VmalVU?= =?utf-8?B?RTNWT2JvYjMwbExKWHQ3ZUFtREtPZkFVR1VUaWIxYXFlS2d1dElobUUvYXhU?= =?utf-8?B?dWlzSmlEMTBDUXR4OEJSU0pFbElXR0haUFJJSUErL0o5U21qc0pHbmNmcGoy?= =?utf-8?B?d1NCWUJxZ1lSRDdKakZHa3hxaWJXZFBvVWJGNjd3NUlpanBlWlNSUzhwM1VW?= =?utf-8?B?aHp4ajMybmYvVzZJSHNKYnRQRFp4cTdKUEtNOVBHUzF4ZHVZNnErZHlBdEkz?= =?utf-8?B?TU1VUmRlWC9JZ3dGZTRkQ2R1SkdrRFY1QUN0THZuTzJxRTFjVnBWdi9iY1N3?= =?utf-8?B?b25UYW5EU0xLWHBOMVU4dDFuREVseXJReXpXVFVTRjBCWmQyZC9KRExFUFV5?= =?utf-8?B?Z25wTFBvcGNaZFNQcUl2UEtSdHNNeFdrT1hiM25Hc2p1M0Nra0VFVEplNHZu?= =?utf-8?B?MWpjZzQ1Sm94Tk1xOHlJbVJoRElnRmZmSitja2lLTG9YWFlWTVpoTkwyTDFU?= =?utf-8?B?K0NHUzJaSnZtN0FYYmRNNVNsQjJhbU8xeW9PanFVYVg4M3p4UzViS0lTMk1M?= =?utf-8?Q?HRhw=3D?= X-Microsoft-Antispam-Message-Info: msqHFUXLg8kg/SZ3zeXgomyVnuEOubGuRvbiWjKn6J9f2yJ7g12Uysa6gB8FnUDldJWEsuYgWR2GfmxyHqQ3C47nyzWFpvPV2vvy31pmmty5sb9KbBHYMNwZJo6+CWYQejnBy5HUJ+IaZUK0cbuEUuqKNbrJ5Bf7eTeG7fQrLdqubbT2lTttp4lnwKnQlmdjFR3s4MnXZ/kXqV753nFEmHbkMY63Fao0TnthAhioz/mZXkatcosJLqEYqJM7YIGFO51Vcj1eq9pD9OhjBCQQ+Db6I9/VOr+SidXlj72Ady7zwyUjCgAWY/jcMCG1B/G+vU34tmA1OPlgeV/8rPlCz/mt6ojaLKQKpXjgNzbvt/U= X-Microsoft-Exchange-Diagnostics: 1; BYAPR07MB4999; 6:f/xxDNJanixaVJQCqq0tv2UjNRRr0L/LW3+IyZxEFx23RkWLUw8Fz+qF32eFtAH04gw07xhyX+GIiBpOXQKJfMkO+7aVLRcFBOVx+5tO6hdIa2bwdrQb7hVZLb8seLg1Bq+tWu62Cssf0t428vXIRri1AamFy91d9sdLirrTpAEhPbEXXsezcf5BZLx4Zwjbv0Xl8bvj6a99kIIQzUT/KusvOJQC725WV+gO1eFmgGc+rhEIG4z9mihNhJ4ANMOapsZbRU7XQve3YEakiChaaocLHFZX0pUo1+7soVdUZdJG+GR/VNnLJbmusEhD9wSmB40Uk3tW0fH4txgvOvPoPsU4bePlkzPGTE7HNSMjFYQR4MriQGJ7EvfKqn8iQwU3YgOjS4HuNBqN/SMREGoDoQgRrs6my//1xAH3grZ8lTO6GyG3sUirDQ8cnWya86RWWDdLWrpYWtePDVYJV1FkJg==; 5:Mz72dy4Y7Y/JvthMETNcpvx5jq4yV3UOFXdslJETEEAOH8PPvj8aXtukGswWnbWsLo0dNn5ielQQFPxfbgC02KSRcCS5paagNV8kFWRBiFIHAYp2uA77RLRjBtUNcdTgG9kU8tz+5cf7z1bKQ7FU10T3AYW8zdN7gG++g6yQqY4=; 7:mJW9lQec1lSNzOvRRSeqiAi0YgM5E2y4tmsrXDAzZP5gE81aGY+mIiWj/98iZD2A45e4dVHb1f+nYa10q7/DiHoEvtvWsyppRMOA4pE73q6WfYhSHVx8PS/0qBbbgYrLF54mtXtpEPpN3EN8a5EerB2FEavLNsIEQEZAhp8pUs+Q/tWydz9en+bQA8LhErqchKoz6P3piPvzOpdykmAumJtOZsIWoh5kvAQYzsRl6FEzPRL8rxXWlo1OAswKloxN SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2018 09:55:30.7518 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8225a3a1-a848-4efe-8c0c-08d627840bbd X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR07MB4999 Subject: Re: [dpdk-dev] [PATCH v11 0/7] hot-unplug failure handle mechanism 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, 01 Oct 2018 09:55:44 -0000 -----Original Message----- > Date: Mon, 1 Oct 2018 11:00:12 +0200 > From: Stephen Hemminger > To: Jeff Guo > Cc: bruce.richardson@intel.com, ferruh.yigit@intel.com, > konstantin.ananyev@intel.com, gaetan.rivet@6wind.com, > jingjing.wu@intel.com, thomas@monjalon.net, motih@mellanox.com, > matan@mellanox.com, harry.van.haaren@intel.com, qi.z.zhang@intel.com, > shaopeng.he@intel.com, bernard.iremonger@intel.com, > arybchenko@solarflare.com, wenzhuo.lu@intel.com, > anatoly.burakov@intel.com, jblunck@infradead.org, shreyansh.jain@nxp.com, > dev@dpdk.org, helin.zhang@intel.com > Subject: Re: [dpdk-dev] [PATCH v11 0/7] hot-unplug failure handle mechanism > > > On Sun, 30 Sep 2018 19:29:56 +0800 > Jeff Guo wrote: > > > Hotplug is an important feature for use-cases like the datacenter device's > > fail-safe and for SRIOV Live Migration in SDN/NFV. It could bring higher > > flexibility and continuality to networking services in multiple use-cases > > in the industry. So let's see how DPDK can help users implement hotplug > > solutions. > > > > We already have a general device-event monitor mechanism, failsafe driver, > > and hot plug/unplug API in DPDK. We have already got the solution of > > “ethdev event + kernel PMD hotplug handler + failsafe”, but we still not > > got “eal event + hotplug handler for pci PMD + failsafe” implement, and we > > need to considerate 2 different solutions between uio pci and vfio pci. > > > > In the case of hotplug for igb_uio, when a hardware device be removed > > physically or disabled in software, the application needs to be notified > > and detach the device out of the bus, and then make the device invalidate. > > The problem is that, the removal of the device is not instantaneous in > > software. If the application data path tries to read/write to the device > > when removal is still in process, it will cause an MMIO error and > > application will crash. > > > > In this patch set, we propose a PCIe bus failure handler mechanism for > > hot-unplug in igb_uio. It aims to guarantee that, when a hot-unplug occurs, > > the application will not crash. > > > > The mechanism should work as below: > > > > First, the application enables the device event monitor, registers the > > hotplug event’s callback and enable hotplug handling before running the > > data path. Once the hot-unplug occurs, the mechanism will detect the > > removal event and then accordingly do the failure handling. In order to > > do that, the below functionality will be required: > > - Add a new bus ops “hot_unplug_handler” to handle hot-unplug failure. > > - Implement pci bus specific ops “pci_hot_unplug_handler”. For uio pci, > > it will be based on the failure address to remap memory for the corresponding > > device that unplugged. For vfio pci, could seperate implement case by case. > > > > For the data path or other unexpected behaviors from the control path > > when a hot unplug occurs: > > - Add a new bus ops “sigbus_handler”, that is responsible for handling > > the sigbus error which is either an original memory error, or a specific > > memory error that is caused by a hot unplug. When a sigbus error is > > captured, it will call this function to handle sigbus error. > > - Implement PCI bus specific ops “pci_sigbus_handler”. It will iterate all > > device on PCI bus to find which device encounter the failure. > > - Implement a "rte_bus_sigbus_handler" to iterate all buses to find a bus > > to handle the failure. > > - Add a couple of APIs “rte_dev_hotplug_handle_enable” and > > “rte_dev_hotplug_handle_diable” to enable/disable hotplug handling. > > It will monitor the sigbus error by a handler which is per-process. > > Based on the signal event principle, the control path thread and the > > data path thread will randomly receive the sigbus error, but will call the > > common sigbus process. When sigbus be captured, it will call the above API > > to find bus to handle it. > > > > The mechanism could be used by app or PMDs. For example, the whole process > > of hotplug in testpmd is: > > - Enable device event monitor->Enable hotplug handle->Register event callback > > ->attach port->start port->start forwarding->Device unplug->failure handle > > ->stop forwarding->stop port->close port->detach port. > > > > This patch set would not cover hotplug insert and binding, and it is only > > implement the igb_uio failure handler, the vfio hotplug failure handler > > will be in next coming patch set. > > > > patchset history: > > v11->v10: > > change the ops name, since both uio and vfio will use the hot-unplug ops. > > add experimental tag. > > since we plan to abandon RTE_ETH_EVENT_INTR_RMV, change to use > > RTE_DEV_EVENT_REMOVE, so modify the hotplug event and callback usage. > > move the igb_uio fixing part, since it is random issue and should be considarate > > as kernel driver defect but not include as this failure handler mechanism. > > > > v10->v9: > > modify the api name and exposure out for public use. > > add hotplug handle enable/disable APIs > > refine commit log > > > > v9->v8: > > refine commit log to be more readable. > > > > v8->v7: > > refine errno process in sigbus handler. > > refine igb uio release process > > > > v7->v6: > > delete some unused part > > > > v6->v5: > > refine some description about bus ops > > refine commit log > > add some entry check. > > > > v5->v4: > > split patches to focus on the failure handle, remove the event usage > > by testpmd to another patch. > > change the hotplug failure handler name. > > refine the sigbus handle logic. > > add lock for udev state in igb uio driver. > > > > v4->v3: > > split patches to be small and clear. > > change to use new parameter "--hotplug-mode" in testpmd to identify > > the eal hotplug and ethdev hotplug. > > > > v3->v2: > > change bus ops name to bus_hotplug_handler. > > add new API and bus ops of bus_signal_handler distingush handle generic. > > sigbus and hotplug sigbus. > > > > v2->v1(v21): > > refine some doc and commit log. > > fix igb uio kernel issue for control path failure rebase testpmd code. > > > > Since the hot plug solution be discussed serval around in the public, > > the scope be changed and the patch set be split into many times. Coming > > to the recently RFC and feature design, it just focus on the hot unplug > > failure handler at this patch set, so in order let this topic more clear > > and focus, summarize privours patch set in history “v1(v21)”, the v2 here > > go ahead for further track. > > > > "v1(21)" == v21 as below: > > v21->v20: > > split function in hot unplug ops. > > sync failure hanlde to fix multiple process issue fix attach port issue for multiple devices case. > > combind rmv callback function to be only one. > > > > v20->v19: > > clean the code. > > refine the remap logic for multiple device. > > remove the auto binding. > > > > v19->18: > > note for limitation of multiple hotplug, fix some typo, sqeeze patch. > > > > v18->v15: > > add document, add signal bus handler, refine the code to be more clear. > > > > the prior patch history please check the patch set "add device event monitor framework". > > > > Jeff Guo (7): > > bus: add hot-unplug handler > > bus/pci: implement hot-unplug handler ops > > bus: add sigbus handler > > bus/pci: implement sigbus handler ops > > bus: add helper to handle sigbus > > eal: add failure handle mechanism for hot-unplug > > testpmd: use hot-unplug failure handle mechanism > > > > app/test-pmd/testpmd.c | 39 ++++++-- > > doc/guides/rel_notes/release_18_08.rst | 5 + > > drivers/bus/pci/pci_common.c | 81 ++++++++++++++++ > > drivers/bus/pci/pci_common_uio.c | 33 +++++++ > > drivers/bus/pci/private.h | 12 +++ > > lib/librte_eal/bsdapp/eal/eal_dev.c | 14 +++ > > lib/librte_eal/common/eal_common_bus.c | 43 +++++++++ > > lib/librte_eal/common/eal_private.h | 39 ++++++++ > > lib/librte_eal/common/include/rte_bus.h | 34 +++++++ > > lib/librte_eal/common/include/rte_dev.h | 26 +++++ > > lib/librte_eal/linuxapp/eal/eal_dev.c | 162 +++++++++++++++++++++++++++++++- > > lib/librte_eal/rte_eal_version.map | 2 + > > 12 files changed, 481 insertions(+), 9 deletions(-) > > > > I am glad to see this, hotplug is needed. But have a somewhat controversial > point of view. The DPDK project needs to do more to force users to go to > more modern kernels and API's; there has been too much effort already to > support new DPDK on older kernels and distributions. This leads to higher > testing burden, technical debt and multiple API's. > > To take the extreme point of view. > * igb_uio should be deprecated and all new work only use vfio and vfio-ionommu only > * kni should be deprecated and replaced by virtio +1 I think, The only feature missing in upstream kernel for DPDK may be to enable SRIOV on PF VFIO devices controlled by DPDK PMD. I think, Binding a PF device to DPDK along with VFs(VF can be bound to netdev or DPDK PMDs, Though binding VF to netdev considered as security breach) will be useful for a) rte_flow actions like redirecting the traffic to PF or VF on the given pattern b) Some NICs can support promiscuous mode only on PF c) Enable Switch representation devices https://doc.dpdk.org/guides/prog_guide/switch_representation.html I think, igb_uio mainly used as the backdoor for this use case. I think, there was some work in this area but it is not upstreamed due to various reasons. https://lkml.org/lkml/2018/3/8/1122 > > When there are N ways of doing things against X kernel versions, > and Y distributions, and multiple device vendors; the combinational explosion of cases means > that interfaces don't get the depth of testing they deserve. > > That means why not support hotplug on VFIO only? >