From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 5CC291B581 for ; Thu, 11 Oct 2018 13:55:03 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 89504B00060; Thu, 11 Oct 2018 11:55:01 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Oct 2018 12:54:55 +0100 To: Thomas Monjalon CC: , , , , References: <20180907230958.21402-1-thomas@monjalon.net> <20181007220933.4533-2-thomas@monjalon.net> <21a07d94-44cc-9e99-1474-a13de77915ea@solarflare.com> <2290243.n1gutIJ8el@xps> From: Andrew Rybchenko Message-ID: <58501734-4a92-2ce6-55b9-43f30c1f12ce@solarflare.com> Date: Thu, 11 Oct 2018 14:54:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <2290243.n1gutIJ8el@xps> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24148.003 X-TM-AS-Result: No-21.989100-8.000000-10 X-TMASE-MatchedRID: +f/wAVSGjugOwH4pD14DsPHkpkyUphL9uLwbhNl9B5X4JyR+b5tvoOln +pgUTqXBuIA/hwcjvFZuTK43U2r81q23CuWprcjSA9lly13c/gHUqhJbkmLVe/002DXYmoa1Wtc VmlHQcwoFIQK4YsYDXkajIAl7Mi8mQRHl12CcQN79vE/QVDV5IZSL3AH2CZxKw01zN1c0miIwKY tIU69m3aoW273DH7Xh4YS6FyG8vyjyUQNiagGSs9sfxZpQv2qMm/y00tE9Sta/wz3p7pLVvSxZV 2XdhwOw7fNKgmEEsE1qlnm6jwp3D3ASplscW9qaZjQijgrFvzoN5rzymY/8/jssXelfet1UuPFr kRUFXWrnzlXMYw4XMAGLeSok4rrZIAcCikR3vq8uRneGSkqDy1xMb3W0yvRKuCiHvPnEv3VLEcL pGjHF9Kv+cfQAva2P X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--21.989100-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24148.003 X-MDID: 1539258902-2snPWUj8u_Bi Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v3 1/3] drivers/bus: move driver assignment to end of probing 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, 11 Oct 2018 11:55:03 -0000 On 10/11/18 2:45 PM, Thomas Monjalon wrote: > 11/10/2018 12:53, Andrew Rybchenko: >> On 10/8/18 1:09 AM, Thomas Monjalon wrote: >>> The PCI mapping requires to know the PCI driver to use, >>> even before the probing is done. That's why the PCI driver is >>> referenced early inside the PCI device structure. See >>> 1d20a073fa5e ("bus/pci: reference driver structure before mapping") >>> >>> However the rte_driver does not need to be referenced in rte_device >>> before the device probing is done. >>> By moving back this assignment at the end of the device probing, >>> it becomes possible to make clear the status of a rte_device. >>> >>> Signed-off-by: Thomas Monjalon >>> --- >>> diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c >>> index c7695d108..d63e68045 100644 >>> --- a/drivers/bus/pci/pci_common.c >>> +++ b/drivers/bus/pci/pci_common.c >>> @@ -160,14 +160,12 @@ rte_pci_probe_one_driver(struct rte_pci_driver *dr, >>> * driver flags for adjusting configuration. >>> */ >>> dev->driver = dr; >>> - dev->device.driver = &dr->driver; >> It breaks net/sfc and I guess other drivers which use >> rte_eth_dma_zone_reserve() >> from probe. The function makes zone name using dev->device->driver->name. > Please, can you show code line where we does such access? > > I checked such access before and did not find some. > Anyway, it can be fixed by accessing rte_pci_driver->driver->name. > Note that rte_pci_driver is referenced in rte_pci_device. Below in snprintf(), in theory it can be called for vdev as well. const struct rte_memzone * rte_eth_dma_zone_reserve(const struct rte_eth_dev *dev, const char *ring_name,                          uint16_t queue_id, size_t size, unsigned align,                          int socket_id) {         char z_name[RTE_MEMZONE_NAMESIZE];         const struct rte_memzone *mz;         snprintf(z_name, sizeof(z_name), "%s_%s_%d_%d",                  dev->device->driver->name, ring_name,                  dev->data->port_id, queue_id);         mz = rte_memzone_lookup(z_name);         if (mz)                 return mz;         return rte_memzone_reserve_aligned(z_name, size, socket_id,                         RTE_MEMZONE_IOVA_CONTIG, align); }