[ofa-general] vendor_id in struct ib_device_attr

Jason Gunthorpe jgunthorpe at obsidianresearch.com
Mon Jun 23 13:02:13 PDT 2008


On Mon, Jun 23, 2008 at 12:47:14PM -0700, Roland Dreier wrote:
>  > If you are using the vendor_id to key sillicon specific optimizations
>  > then I'd think it is better to look at the PCI ID rather than the
>  > OUI. The OUI belongs to whoever sticks the chip on a card, and has no
>  > relation to the sillicon capabilities..
> 
> PCI vendor ID is pretty much the same boat though.

Well, the way PCI ID usually works is that the sillicon vendor bakes
their ID into the chip and then allows downstream vendors to alter
the subsytem id, ie:

04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express (rev 02)
        Subsystem: Dell Unknown device 01de
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:13:72:29:e6:5d brd ff:ff:ff:ff:ff:ff
001372     (base 16)		Dell Inc.

So unless people are abusing this, a PCI ID is tied to a piece of
sillicon, while OUI+Subsystem ID+GUID/MAC is tied to the board
vendor.. So, yes, there tend to be many PCI IDs for sillicon that is
very similar, but the OUI tells you nothing about the underlying
sillicon.

Using an OUI to trigger sillicon specific tuning only works while we
have a small set of suppliers.

I'm just commenting on Jeff's use of the vendor_id in OMPI, I have no
real opinion on what should go in the structure member.

> OUI at least has the benefit that it's sensible for non-PCI devices such
> as IBM ehca.

IBM has a vendor ID, they could assign a device ID in their space to the
ehca..

Jason



More information about the general mailing list