From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 7111D2B99 for ; Thu, 28 Sep 2017 15:50:37 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 06:50:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,450,1500966000"; d="scan'208,217";a="317265187" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by fmsmga004.fm.intel.com with ESMTP; 28 Sep 2017 06:50:35 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.22]) by IRSMSX106.ger.corp.intel.com ([169.254.8.36]) with mapi id 14.03.0319.002; Thu, 28 Sep 2017 14:50:34 +0100 From: "Trahe, Fiona" To: "dev@dpdk.org" CC: "Trahe, Fiona" Thread-Topic: Sharing a PCI device between multiple PMDs Thread-Index: AdM4Xhfe50pKw62+Q9KIo4Tzm/mU2Q== Date: Thu, 28 Sep 2017 13:50:34 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B4358929C850@IRSMSX101.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODQ3MGU4MGEtOTA2My00MjdiLTllOTktNDVmMjg2ZDJiZThkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjdIeFRKN0RLOHZ6WkpsOVM2WGI0Q3FJYVVGU2V3ZlRtdkNSV0xLNDFlUUk9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.182] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] Sharing a PCI device between multiple PMDs 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: Thu, 28 Sep 2017 13:50:38 -0000 Thanks to all for your feedback on above topic at the DPDK userspace summit= . I've summarised the feedback below - left out names as I'm paraphrasing and= don't want to misrepresent anyone. * One vendor has tried same approach, ran into similar problems with = knock-on impacts to eth-dev, has instead worked around by not sharing the d= evice, instead allocating different VFs to different PMDs. Needs a modifica= tion of whitelist functionality, maybe extra cmdline parameters to do this. * Another vendor also tried similar, wanting to create a device per p= ort. Had limitations with interrupts. Worked around by handling within one = PMD instead of a generic solution within EAL. * Several suggestions related to resolving in other ways within EAL, = e.g. o any driver which can share a device could append a new device to the en= d of the bus device-list during its probe, in effect it takes the resources= it needs, the remainder of the device is appended to the device-list where= it can be found by another driver. Questions re where the shared data coul= d be stored and how attach/detach would work. o a variant of this could be a master driver claims the PCI device - spaw= ning multiple slave devices which are then claimed by service-specific driv= ers. Probably easier to manage the attach/detach and shared data with this = approach. o create a new bus type, one PCI device driver could create sub-devices o= n a sub-bus - these devices could be shared as the bus would have its own p= robe/remove fns and type-specific structs. * Stick with one PMD per device and hide the sharing of multiple func= tions within this PMD. Next steps: Though this does seem to be a generic problem, I'm not now planning to push= a patch relating to this. Instead to work on one PMD claiming one device, but being able to implement= multiple APIs. So an application could see 2 independent devices each serv= icing a different API while only one PMD implements them both using the sam= e underlying hardware. I have ideas now for how this can work, if it does, = then there's no need for separate drivers for the same PCI device. Regards, Fiona