From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com [209.85.192.182]) by dpdk.org (Postfix) with ESMTP id 526691C0B for ; Fri, 23 Jun 2017 19:47:26 +0200 (CEST) Received: by mail-pf0-f182.google.com with SMTP id s66so26475689pfs.1 for ; Fri, 23 Jun 2017 10:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=p/zGHFBHgT8KQcwnDfGJuU8iIQXRafTgjPNw3uTz0kA=; b=l7g8z2eO7yQMGrhjbvPObbann00hCeWwyptVMOkeUybrdAC861JayNcSwPXrbM5R/r N1fdQm0XpQiE53kwp2xHm0w3h5hlTu2cCwTtON4bF1j4rY4kOy7dLxxu9fJqt9Inx7V5 qT99FMWrbYctUoDXZ7VKxhZND2AI2v0GFEgWNSWdk3gkI/7E1SP9OeYErGrVZbwt3Oxl 5Sj8TkWVRGjj6j3z4XjzUVzBDPM4mjpt9wTa1zXPslhp2kzvyP+qyMBo9urh8FW03KbS t21huJVX7Ifwod5YBaIzCcS3oCgJAdW2enVMG+rRbkThyMcFHfq0miTzicq8qCZLCtnd 8lIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=p/zGHFBHgT8KQcwnDfGJuU8iIQXRafTgjPNw3uTz0kA=; b=U0Nh21oC5xDaeqKrSspAkhGkZPE595DwpIJidzn7psTH049K/7gukqEvCnVUw+qu66 W926CrZ+6k9hRG0MZ4lbMHP97UV4RRun3nwRh47fUbuamReBAezOSCKcSSho6q2aFfgQ u6QLBG6Gq9Y6dIg5/2EKokrT6pVmo+ksFzrzx6Ud2lV53R2+Q/7tOl7eh5rfED2eYYKQ XjbwoQCUHVZCCOUv1s2oYaALTedsqh5jzkN1hwUp+HYwia84rEQPT4kClKxo1fxgS/7+ SqlX4J16Z/XAUI/Ggj5U+1XoYhk/zesgYz5PDqunXV5onKJwZrLQq0es4nVX3VblqAqU J0KQ== X-Gm-Message-State: AKS2vOxfqvtY3mkL/VhJrpbRhKwe1kOyP5H3nYr6SZOfC26c3Xel56bp JsZ399+pBj0vnUmcfv/NMg== X-Received: by 10.84.130.98 with SMTP id 89mr10184120plc.222.1498240045601; Fri, 23 Jun 2017 10:47:25 -0700 (PDT) Received: from xeon-e3 (76-14-207-240.or.wavecable.com. [76.14.207.240]) by smtp.gmail.com with ESMTPSA id n71sm11059137pfi.95.2017.06.23.10.47.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 23 Jun 2017 10:47:25 -0700 (PDT) Date: Fri, 23 Jun 2017 10:47:23 -0700 From: Stephen Hemminger To: "Chang, Cunyin" Cc: "dev@dpdk.org" , Stephen Hemminger Message-ID: <20170623104723.52069936@xeon-e3> In-Reply-To: <2BFA8F2383C3784C90698C10BC0963195EEEF974@SHSMSX103.ccr.corp.intel.com> References: <20170621163545.25713-1-stephen@networkplumber.org> <20170621163545.25713-3-stephen@networkplumber.org> <2BFA8F2383C3784C90698C10BC0963195EEEF678@SHSMSX103.ccr.corp.intel.com> <20170622085134.598451d3@xeon-e3> <2BFA8F2383C3784C90698C10BC0963195EEEF974@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 2/3] eal: PCI domain should be 32 bits 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: Fri, 23 Jun 2017 17:47:26 -0000 On Fri, 23 Jun 2017 00:41:43 +0000 "Chang, Cunyin" wrote: > > -----Original Message----- > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > Sent: Thursday, June 22, 2017 11:52 PM > > To: Chang, Cunyin > > Cc: dev@dpdk.org; Stephen Hemminger > > Subject: Re: [dpdk-dev] [PATCH 2/3] eal: PCI domain should be 32 bits > > > > On Thu, 22 Jun 2017 09:28:31 +0000 > > "Chang, Cunyin" wrote: > > > > > I think the series patches does not cover all area which need to adapt > > > to u32 PCI domain, We still need some other work to do: > > > we need define another macro such as PCI_PRI_FMT. Something like: > > > #define PCI_XXX_PRI_FMT "%.5" PRIx32 ":%.2" PRIx8 ":%.2" PRIx8 ".%" > > > PRIx8 > > > > > > PCI_PRI_STR_SIZE also need to be modified: > > > #define PCI_PRI_STR_SIZE sizeof("XXXXX:XX:XX.X") > > > > > > The macro PCI_PRI_FMT will not works if The domain exceed 16bits. It > > > will impact the following functions: > > > 1 RTE_LOG function, there a lots of RTE_LOG such as: > > > RTE_LOG(WARNING, EAL, > > > "Requested device " PCI_PRI_FMT " cannot be > > used\n", > > > addr->domain, addr->bus, addr->devid, addr- > > >function); > > > 2 pci_dump_one_device(). > > > 3 rte_eal_pci_device_name() > > > 4 pci_update_device() > > > 5 pci_ioport_map() > > > 6 pci_get_uio_dev() > > > 7 pci_uio_map_resource_by_index() > > > 8 pci_uio_ioport_map() > > > 9 pci_vfio_map_resource() > > > 10 pci_vfio_unmap_resource() > > > All the above functions will related with the macro PCI_PRI_FMT, so I think > > they need to be modified too. > > > > > > There are some other code need modify: > > > In function rte_eal_compare_pci_addr(), we need do the following work: > > > dev_addr = ((uint64_t)addr->domain << 24) | ((uint64_t)addr->bus << 16) | > > > ((uint64_t)addr->devid << 8) | > > (uint64_t)addr->function; > > > dev_addr2 = ((uint64_t)addr2->domain << 24) | ((uint64_t)addr2->bus << > > 16) | > > > ((uint64_t)addr2->devid << 8) | > > (uint64_t)addr2->function; > > > > > > In function eal_parse_pci_BDF(), we need do the following work: > > > GET_PCIADDR_FIELD(input, dev_addr->domain, UINT32_MAX, ':'); > > > > Good catch, the string size must be increased. > > > > It turns out that you don't need to change the PCI print format. Printing the > > domain with %.4x works correctly with 32 bit. It just gets wider. This is how > > pciutils works, so no change is necessary there. > > I suppose we should use %4x, not %.4x?, the %.4x will cut the 10000:05:00.0 as 0000:05:00.0. > So the macro: > #define PCI_PRI_FMT "%.4" PRIx32 ":%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8 > Should be: > #define PCI_PRI_FMT "%4" PRIx32 ":%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8 > > Make sense? No, that format would not be correct. I want to keep the visible output the same for the normal case of 16 bit domains. Output of printf test program shows that %.4x is the correct format to use. Domain %4x %.4x %4.4x 0 0 0000 0000 0x1 1 0001 0001 0x1000 1000 1000 1000 0x10000 10000 10000 10000 0x12345678 12345678 12345678 12345678 0xdeadbeef deadbeef deadbeef deadbeef