From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: PCI domain size Date: Wed, 07 Jun 2017 16:23:09 +0200 Message-ID: <4912406.Tfa8CUZAWC@xps> References: <20170524164008.4d4e8e7b@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: Stephen Hemminger Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id B522E2BBB for ; Wed, 7 Jun 2017 16:23:10 +0200 (CEST) In-Reply-To: <20170524164008.4d4e8e7b@xeon-e3> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 25/05/2017 01:40, Stephen Hemminger: > While working on SR-IOV support on Azure, it was discovered that some applications > and drivers do not support full size PCI domains. On Azure environment the PCI pass > through device has a synthetic domain value (ie generated by host) which is > 16 bits. > > The common PCI utilities (pci-utils) and Linux kernel both support > full 32 bits but DPDK does not. FreeBSD also supports 32 bit domains. > > Changing the one place in DPDK (rte_pci.h) in source is trivial but of course > it is a major ABI breakage which is a complete flag day. I.e no binary compatiabilty > is possible. I guess you are talking about struct rte_pci_addr { uint16_t domain; uint8_t bus; uint8_t devid; uint8_t function; }; I do not see why we would not change it to comply to the standard. Do you want to propose a deprecation?