Re: [dpdk-dev] 答复: Port-ids and NIC features

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 16 Aug 2013 00:15:04 +0200
Marc Sune <marc.sune@bisdn.de> wrote:

> Dear Stephen,
> 
> 1) The problem is that, if the interfaces are binded to the IGB_UIO
> driver *before* the DPDK-based application is started, there is no way,
> as far as I've seen, to get such information. Of course, you cannot use
> anymore ethtool or whatever to get at least the speeds that the card is
> supporting. Btw, I don't need them, but offloads would probably be also
> quite useful. So in general all the "features" or "capabilities"
> supported by the NIC.

The hack for now is doing:

		struct rte_eth_dev_info dev_info;
		rte_eth_dev_info_get(portid, &dev_info);

		if (strncmp(dev_info.driver_name, "rte_ixgbe", 9) == 0)
			/* do stuff for 10G */
                else
                        /* do stuff for 1G */

Obviously, the driver_name approach could be generalized to a lookup table.
But it really won't scale when many more drivers are added.
Also since speed is negotiable, code should really wait till link is
up to look at link speed and decide from that.

Since device is totally owned by user driver at this point, it
is perfectly possible to extend the existing drivers to do more PHY interaction
to query/set speed and duplex. The current code just assumes autonegotiation.
Since the Intel drivers are based off of BSD source there still is unused
code to do this (I think).