From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH] qat: fix for VFs not getting recognized Date: Fri, 17 Jun 2016 15:12:42 +0530 Message-ID: <20160617094241.GA32149@localhost.localdomain> References: <1466090950-12231-1-git-send-email-deepak.k.jain@intel.com> <11386705.985BuDGx4F@xps13> <7138878.rfgI980QT2@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "Jain, Deepak K" , , "Griffin, John" , "De Lara Guarch, Pablo" , "Doherty, Declan" To: Thomas Monjalon Return-path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0077.outbound.protection.outlook.com [157.56.111.77]) by dpdk.org (Postfix) with ESMTP id E6385CC1E for ; Fri, 17 Jun 2016 11:43:11 +0200 (CEST) Content-Disposition: inline In-Reply-To: <7138878.rfgI980QT2@xps13> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Jun 17, 2016 at 10:18:30AM +0200, Thomas Monjalon wrote: > 2016-06-16 16:25, Jain, Deepak K: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > 2016-06-16 16:29, Jain, Deepak K: > > > > Due to addition of CLASS_ID in EAL, class_id is amended into the code. > > > > > > Why the VF is not recognized? > > > The class id should not be mandatory. > > > > Without the change proposed, QuickAssist Devices were not visible and hence tests were not running. > > Seems like changes in EAL especially where class_id is added affected the QuickAssist tests. > > With this change, QuickAssist devices are visible during tests and tests working fine. > > Which tests? > Have you investigated why? Thunderx nicvf also got the same problem when I rebased to dpdk-next-net/rel_16_07. The root cause for this issue is that, PCI CLASS_ID EAL add changeset(701c8d80c820461e8255dfb7387a09f0e54399f0) has taken care only the pci devices where id table is created with RTE_PCI_DEVICE For other devices, class_id comes as 0 instread of RTE_CLASS_ANY_ID and probe failes. To fix it, one option is to add RTE_CLASS_ANY_ID for the devices where pci id table is not created with RTE_PCI_DEVICE or somewhere in common-code in the initaization set if class_id = 0 then make it as RTE_CLASS_ANY_ID(Thats would be a hack). Seems like first option is correct-way to fix the problem? Any thoughts? looks like following devices does not exhibit this issue [dpdk-thunderx] $ grep -r "RTE_PCI_DEVICE" drivers/ drivers/net/szedata2/rte_eth_szedata2.c: drivers/net/bnx2x/bnx2x_ethdev.c drivers/net/vmxnet3/vmxnet3_ethdev.c drivers/net/enic/enic_ethdev.c drivers/net/e1000/em_ethdev.c drivers/net/ena/ena_ethdev.c drivers/net/qede/qede_ethdev.c drivers/net/ixgbe/ixgbe_ethdev.c:#define RTE_PCI_DEV_ID_DECL_IXGBE(vend, drivers/net/virtio/virtio_ethdev.c:#define drivers/net/i40e/i40e_ethdev.c:vend, Jerin