The PCI configuration space is a well known and well used piece of infrastructure.  Most people are very familiar with how to use it, but there is often questions about Best Known Methods for dealing with some of the less often used pieces of it.  I'm not going to go into all the fields, (as you could probably tell from the title), I'm just going to cover the "Subs".

Technically known as Subsystem Device ID and Subsystem Vendor ID, they are used to differentiate between the original equipment manufacturer and the implementation manufacturer.  For your Intel networking design, the Vendor ID will be Intel's 8086, and the Device ID will depend on what product your using.  The "Subs" are used to show that possibly somebody else has touched the design.  On Intel® adapters, these will be Intel values.  On your implementation, they need to point to you.  You did the hard work, time to get credit for it.


Let talk semantics for a moment.   How best to talk about these field?  In Computer Science Theory these are described as "tuples*". Internally we use a short hand that mirrors the way it's described in most install files.  We list Vendor/Device/Sub Vendor/Sub Device just like that, calling it a 4 tuple match.  I'll use this w/x/y/z for the rest of the post.  I'll spare you any deeper "tuple" talk until we get to NDIS driver installs, which is a whole 'nother post.


If pictures are worth a thousand words, then examples are worth at least 250.  Disclaimer: The following example with uses made up numbers at the time I made this post.  If it ends up with somebody's real Vendor ID, I'm sorry.  Mythical company Dad's Widget Co is making a LAN on Motherboard implementation using an Intel networking part.  Dad's Widget Co has a PCI device ID of 0x0DAD.  Their Device would go into the SubVendor field in our example.  So using the Intel® 82574 Ethernet Controller as an example it would look like this: 8086/10D4/0DAD/????

Whoops!  What goes into the last field?

That part is up to you and the needs of your organization.  Some people just start at 1 (0 causes troubles with some people so don't use it)  and each new design increment it.  Some people just use the device ID.  This field will have context for all your designs with that one Intel controller, so you do need to be keeping track.  Having a scheme for it would be best.  We used to keep track ours in a spreadsheet, but a database is the current state of the art.  No you can't have a copy of it .  Just appoint a "Subs" Chief, head honcho, Big Cheese or Czar whatever a person in charge is called in your organization and they'll figure it all out.


Okay let's check what we've learned using an another set of examples.  Consider if you will, the following set of tuples:

1) 8086/100E/8086/1

2) 8086/100E/0DAD/1

3) 8086/100F/0DAD/1

They look very close, but they are all separate and legal.  One and two have the same device IDs, but different SubVendors so they're okay.  2 and 3 are different Device IDs, so they are okay and 1 and 3 are both different SubVendor and device.


What commonly happens is people think that they can use Intel's values.  Let's say that our mythical Dad's Widget Co, is being naughty, using something like this 4 tuple:  8086/100E/8086/000E as a LOM on a Dad's product.

This will make the LOM look like one of our old Intel® PRO/1000 MT adapters!  Not only will that create support issues, but its not allowed by the PCI specification.  Some major O/S vendors will even not certify your product unless it has the proper tuple values.


Don't have a PCI Vendor ID?  Join the PCI-SIG and you get one as part of your membership.  It's not free, so plan ahead for it.  And use this search to make sure your company doesn't have one already in use.


Just to be clear, everything in this is our recommended methods, but the PCI-SIG is the final answer.


Close with the review:

1)  Use your own Vendor ID in the Subdevice Vendor ID field

2)  Keep track of your own Subsystem Device ID

3)  Thanks for using Intel networking products.


*tuple. The Free On-line Dictionary of Computing. Denis Howe. (accessed: May 11, 2009).