From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from minas.ics.muni.cz (minas.ics.muni.cz [147.251.4.46]) by dpdk.org (Postfix) with ESMTP id B2F311B1AB for ; Mon, 25 Jun 2018 10:23:40 +0200 (CEST) Received: from [192.168.1.18] (ADijon-654-1-70-57.w109-217.abo.wanadoo.fr [109.217.29.57]) (authenticated user=98998@is.muni.cz bits=0) by minas.ics.muni.cz (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w5P8NZws002076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Jun 2018 10:23:38 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Martin_Dra=C5=A1ar?= X-Mailer: iPhone Mail (15F79) In-Reply-To: <9B0331B6EBBD0E4684FBFAEDA55776F9672D250D@HASMSX110.ger.corp.intel.com> Date: Mon, 25 Jun 2018 10:23:35 +0200 Cc: Stephen Hemminger , "Avi Cohen (A)" , "users@dpdk.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <34c3f20b-dcbb-5a47-d8c0-6af6635bc41a@ics.muni.cz> <9B0331B6EBBD0E4684FBFAEDA55776F9672C6986@HASMSX110.ger.corp.intel.com> <5dde9d52-3662-72ae-04a6-b5ad3e122562@ics.muni.cz> <9B0331B6EBBD0E4684FBFAEDA55776F9672C7B30@HASMSX110.ger.corp.intel.com> <9B0331B6EBBD0E4684FBFAEDA55776F9672C7B86@HASMSX110.ger.corp.intel.com> <586d777c-063a-1e0e-a6a8-bdcae3360ed6@ics.muni.cz> <9B0331B6EBBD0E4684FBFAEDA55776F9672CBC5E@HASMSX110.ger.corp.intel.com> <20180621080713.44313c33@xeon-e3> <9B0331B6EBBD0E4684FBFAEDA55776F9672D250D@HASMSX110.ger.corp.intel.com> To: "Rosen, Rami" X-Muni-Envelope-From: drasar@ics.muni.cz X-Muni-Envelope-To: rami.rosen@intel.com X-Muni-Spam-TestIP: 109.217.29.57 X-Muni-Local-Auth: yes X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.9 (minas.ics.muni.cz [147.251.4.35]); Mon, 25 Jun 2018 10:23:39 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.99.4 at minas X-Virus-Status: Clean X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on minas.ics.muni.cz Subject: Re: [dpdk-users] DPDK 17.05 does not find X510 card X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 08:23:40 -0000 Hi, Stephen, thanks four input. I have already read that part of documentation R= ami posted, but that =E2=80=98may disallow=E2=80=99 left me hoping there are= some situations when it is not disallowed. If it is indeed not possible usi= ng the igb uio, I will have to do it with the vfio. However, and that is the= reason why I was doing the dances with the kernel, I was not able to find a= guide to bind the cards to vfio in non-virtual environent, other than a not= ice that all ports must be bound to vfio at once.=20 Can you point me to some resources regarding the iommu and vfio? Thanks,=20 Martin 23. 6. 2018 v 15:00, Rosen, Rami : > Hi all, >=20 >> Secure boot should work with VFIO. As long as you have an IOMMU,=20 >> VFIO is a much better solution. >=20 > Stephen is right; moreover, DPDK documentation says explicitly that > ... > "If UEFI secure boot is enabled, the Linux kernel may disallow the use of U= IO on the system. Therefore, devices for use by DPDK should be bound to the v= fio-pci kernel module rather than igb_uio or uio_pci_generic. For more detai= ls see Binding and Unbinding Network Ports to/from the Kernel Modules below.= " > ... > See section 4.1, "UIO", in: > https://doc.dpdk.org/guides/linux_gsg/linux_drivers.html >=20 > Regards, > Rami Rosen >=20 >=20