From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by dpdk.org (Postfix) with ESMTP id 0E7E41B1A4 for ; Mon, 2 Oct 2017 10:44:33 +0200 (CEST) Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v928iRce141487 for ; Mon, 2 Oct 2017 04:44:33 -0400 Received: from e23smtp06.au.ibm.com (e23smtp06.au.ibm.com [202.81.31.148]) by mx0b-001b2d01.pphosted.com with ESMTP id 2db8wrum23-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 02 Oct 2017 04:44:33 -0400 Received: from localhost by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 2 Oct 2017 18:44:28 +1000 Received: from d23relay09.au.ibm.com (202.81.31.228) by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 2 Oct 2017 18:44:27 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay09.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v928iQsj47055036 for ; Mon, 2 Oct 2017 19:44:26 +1100 Received: from d23av01.au.ibm.com (localhost [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id v928iRAq003150 for ; Mon, 2 Oct 2017 19:44:27 +1100 Received: from [9.77.209.140] ([9.77.209.140]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id v928iJJK002881; Mon, 2 Oct 2017 19:44:21 +1100 To: Raslan Darawsheh , Thomas Monjalon Cc: "dev@dpdk.org" , =?UTF-8?Q?Ga=c3=abtan_Rivet?= , Declan Doherty , Ferruh Yigit References: <20170731143458.GL11154@bidouze.vm.6wind.com> <19317053.0GOQUN8yPN@xps> From: gowrishankar muthukrishnan Date: Mon, 2 Oct 2017 14:14:17 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-TM-AS-MML: disable x-cbid: 17100208-0040-0000-0000-00000358F474 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17100208-0041-0000-0000-00000CDA0750 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-02_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710020125 Subject: Re: [dpdk-dev] [Suspected-Phishing]Re: [PATCH v2] net/bonding: support bifurcated driver in eal cli using --vdev 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, 02 Oct 2017 08:44:34 -0000 Hi Raslan, I had submitted newer version and waiting for ack/merge. dpdk.org/dev/patchwork/patch/29039/ Thanks, Gowrishankar On Monday 02 October 2017 02:11 PM, Raslan Darawsheh wrote: > Hi Guys, > This is gentle remainder of this patch, > Do we have any updates about it? > > Kindest regards > Raslan Darawsheh > > -----Original Message----- > From: gowrishankar muthukrishnan [mailto:gowrishankar.m@linux.vnet.ibm.com] > Sent: Wednesday, September 6, 2017 11:59 AM > To: Thomas Monjalon > Cc: dev@dpdk.org; Gaëtan Rivet ; Declan Doherty ; Ferruh Yigit ; Raslan Darawsheh > Subject: [Suspected-Phishing]Re: [dpdk-dev] [PATCH v2] net/bonding: support bifurcated driver in eal cli using --vdev > > 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, >>> >> -- Regards, Gowrishankar M Linux Networking