From mboxrd@z Thu Jan 1 00:00:00 1970 From: gowrishankar muthukrishnan Subject: Re: [PATCH v2] net/bonding: support bifurcated driver in eal cli using --vdev Date: Wed, 6 Sep 2017 14:29:01 +0530 Message-ID: References:

<20170731143458.GL11154@bidouze.vm.6wind.com> <19317053.0GOQUN8yPN@xps> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: dev@dpdk.org, =?UTF-8?Q?Ga=c3=abtan_Rivet?= , Declan Doherty , Ferruh Yigit , rasland@mellanox.com To: Thomas Monjalon Return-path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by dpdk.org (Postfix) with ESMTP id 1493411D4 for ; Wed, 6 Sep 2017 10:59:22 +0200 (CEST) Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v868xL04055126 for ; Wed, 6 Sep 2017 04:59:22 -0400 Received: from e23smtp05.au.ibm.com (e23smtp05.au.ibm.com [202.81.31.147]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ctd7cj4h2-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 06 Sep 2017 04:59:22 -0400 Received: from localhost by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 6 Sep 2017 18:59:08 +1000 Received: from d23av06.au.ibm.com (d23av06.au.ibm.com [9.190.235.151]) by d23relay10.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v868x5pN38273228 for ; Wed, 6 Sep 2017 18:59:05 +1000 Received: from d23av06.au.ibm.com (localhost [127.0.0.1]) by d23av06.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id v868x54C018997 for ; Wed, 6 Sep 2017 18:59:05 +1000 In-Reply-To: <19317053.0GOQUN8yPN@xps> Content-Language: en-GB List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Thomas, I will rework on my patch with these suggestions and send new version. Thanks Declan and Gaëtan. Thank you Thomas too reminding me. Regards, Gowrishankar On Tuesday 05 September 2017 02:43 PM, Thomas Monjalon wrote: > Ping - any news? > > 31/07/2017 16:34, Gaëtan Rivet: >> Hi Gowrishankar, Declan, >> >> On Mon, Jul 10, 2017 at 12:02:24PM +0530, gowrishankar muthukrishnan wrote: >>> On Friday 07 July 2017 09:08 PM, Declan Doherty wrote: >>>> On 04/07/2017 12:57 PM, Gowrishankar wrote: >>>>> From: Gowrishankar Muthukrishnan >>>>> >>>>> At present, creating bonding devices using --vdev is broken for PMD like >>>>> mlx5 as it is neither UIO nor VFIO based and hence PMD driver is unknown >>>>> to find_port_id_by_pci_addr(), as below. >>>>> >>>>> testpmd --vdev 'net_bonding0,mode=1,slave=,socket_id=0' >>>>> >>>>> PMD: bond_ethdev_parse_slave_port_kvarg(150) - Invalid slave port value >>>>> () specified >>>>> EAL: Failed to parse slave ports for bonded device net_bonding0 >>>>> >>>>> This patch fixes parsing PCI ID from bonding device params by verifying >>>>> it in RTE PCI bus, rather than checking dev->kdrv. >>>>> >>>>> Changes: >>>>> v2 - revisit fix by iterating rte_pci_bus >>>>> >>>>> Signed-off-by: Gowrishankar Muthukrishnan >>>>> >>>>> --- >>>> ... >>>> Hey Gowrishankar, >>>> >>>> I was having a look at this patch and there is the following checkpatch >>>> error. >>>> >>>> _coding style issues_ >>>> >>>> >>>> WARNING:AVOID_EXTERNS: externs should be avoided in .c files >>>> #48: FILE: drivers/net/bonding/rte_eth_bond_args.c:43: >>>> +extern struct rte_pci_bus rte_pci_bus; >>>> >>> Hi Declan, >>> Thank you for your review. >>> Yes, but I also saw some references like above in older code. >>> >>>> Looking at bit closer at the issue I think there is a simpler solution, >>>> the bonding driver really shouldn't be parsing the PCI bus directly, and >>>> since PCI devices use the PCI DBF as their name we can simply replace the >>>> all the scanning code with a simple call to rte_eth_dev_get_port_by_name >>>> API. >>>> >> I agree that it would be better to be able to use the ether API for >> this. >> >> The issue is that PCI devices are inconsistent regarding their names. The >> possibility is given to the user to employ the simplified BDF format for >> PCI device name, instead of the DomBDF format. >> >> Unfortunately, the default device name for a PCI device is in the DomBDF >> format. This means that the name won't match if the device was probed by >> using the PCI blacklist mode (the default PCI mode). >> >> The matching must be refined. >> >>> But you are removing an option to mention ports by PCI addresses right (as >>> I see parse_port_id() completely removed in your patch) ?. >>> IMO, we just need to check if given eth pci id (incase we mention ports ib >>> PCI ID) is one of what EAL scanned in PCI. Also, slaves should not be from >>> any blacklisted PCI ids (as we test with -b or -w). >>> >> Declan is right about the iteration of PCI devices. The device list for >> the PCI bus is private, the extern declaration to the rte_pci_bus is the >> telltale sign that there is something wrong in the approach here. >> >> In order to respect the new rte_bus logic, I think what you want to >> achieve can be done by using the rte_bus->find_device with the correct >> device comparison function. >> >> static int >> pci_addr_cmp(const struct rte_device *dev, const void *_pci_addr) >> { >> struct rte_pci_device *pdev; >> char *addr = _pci_addr; >> struct rte_pci_addr paddr; >> static struct rte_bus *pci_bus = NULL; >> >> if (pci_bus == NULL) >> pci_bus = rte_bus_find_by_name("pci"); >> >> if (pci_bus->parse(addr, &paddr) != 0) { >> /* Invalid PCI addr given as input. */ >> return -1; >> } >> pdev = RTE_DEV_TO_PCI(dev); >> return rte_eal_compare_pci_addr(&pdev->addr, &paddr); >> } >> >> Then verify that you are able to get a device by using it as follows: >> >> { >> struct rte_bus *pci_bus; >> struct rte_device *dev; >> >> pci_bus = rte_bus_find_by_name("pci"); >> if (pci_bus == NULL) { >> RTE_LOG(ERR, PMD, "Unable to find PCI bus\n"); >> return -1; >> } >> dev = pci_bus->find_device(NULL, pci_addr_cmp, devname); >> if (dev == NULL) { >> RTE_LOG(ERR, PMD, "Unable to find the device %s to enslave.\n", >> devname); >> return -EINVAL; >> } >> } >> >> I hope it's clear enough. You can find examples of use for this API in >> lib/librte_eal/common/eal_common_dev.c >> >> It's a quick implementation to outline the possible direction, I >> haven't compiled it. It should be refined. >> >> For example, the PCI address validation should not be happening in the >> comparison function, the pci_bus could be matched once instead of twice, >> etc... >> >> But the logic should work. >> >> Best regards, >> > >