* [dpdk-dev] Port-ids and NIC features @ 2013-08-14 8:56 Marc Sune 2013-08-15 1:51 ` [dpdk-dev] 答复: " 安宏奎 0 siblings, 1 reply; 5+ messages in thread From: Marc Sune @ 2013-08-14 8:56 UTC (permalink / raw) To: dev Dear all, Two quick questions: 1) Is there a way to get the features available in the NIC? In particular, I cannot see a way to retrieve the *maximum speed* of the card and I need to determine whether is a FE, GE or 10GE card. 2) For a certain number of NICs installed in the system and bound to the IGB_UIO driver, is it safe to assume that the association phyisical port <-> port_id will always be the same? Even after reboot, and regardless of the order that are bound to the IGB_UIO driver (e.g. using pci_unbind.py)? Best marc ^ permalink raw reply [flat|nested] 5+ messages in thread
* [dpdk-dev] 答复: Port-ids and NIC features 2013-08-14 8:56 [dpdk-dev] Port-ids and NIC features Marc Sune @ 2013-08-15 1:51 ` 安宏奎 2013-08-15 14:57 ` Stephen Hemminger 0 siblings, 1 reply; 5+ messages in thread From: 安宏奎 @ 2013-08-15 1:51 UTC (permalink / raw) To: 'Marc Sune', dev For the question one, maybe you can detect it before binding to igb_uio -----邮件原件----- 发件人: dev-bounces@dpdk.org [mailto:dev-bounces@dpdk.org] 代表 Marc Sune 发送时间: 2013年8月14日 16:57 收件人: dev@dpdk.org 主题: [dpdk-dev] Port-ids and NIC features Dear all, Two quick questions: 1) Is there a way to get the features available in the NIC? In particular, I cannot see a way to retrieve the *maximum speed* of the card and I need to determine whether is a FE, GE or 10GE card. 2) For a certain number of NICs installed in the system and bound to the IGB_UIO driver, is it safe to assume that the association phyisical port <-> port_id will always be the same? Even after reboot, and regardless of the order that are bound to the IGB_UIO driver (e.g. using pci_unbind.py)? Best marc ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] 答复: Port-ids and NIC features 2013-08-15 1:51 ` [dpdk-dev] 答复: " 安宏奎 @ 2013-08-15 14:57 ` Stephen Hemminger 2013-08-15 22:15 ` Marc Sune 0 siblings, 1 reply; 5+ messages in thread From: Stephen Hemminger @ 2013-08-15 14:57 UTC (permalink / raw) To: 安宏奎; +Cc: dev On Thu, 15 Aug 2013 09:51:00 +0800 安宏奎 <anhk_@126.com> wrote: > For the question one, maybe you can detect it before binding to igb_uio > > > -----邮件原件----- > 发件人: dev-bounces@dpdk.org [mailto:dev-bounces@dpdk.org] 代表 Marc Sune > 发送时间: 2013年8月14日 16:57 > 收件人: dev@dpdk.org > 主题: [dpdk-dev] Port-ids and NIC features > > Dear all, > > Two quick questions: > > 1) Is there a way to get the features available in the NIC? In particular, I > cannot see a way to retrieve the *maximum speed* of the card and I need to > determine whether is a FE, GE or 10GE card. Not at present. You need to look at the information in rte_pci_device for the ethernet (see rte_eth_dev_info) and then do your own matching against ID and features. As DPDK evolves more of the hardware features need to be abstracted to allow applications to be build once and run on varying hardware. IMHO some of the low level features like read/write thresholds really shouldn't be exposed through the API. Setting them correctly depends too much on the underlying hardware, chip version, and driver and really shouldn't be something the application writer has to worry about. > 2) For a certain number of NICs installed in the system and bound to the > IGB_UIO driver, is it safe to assume that the association phyisical port <-> > port_id will always be the same? Even after reboot, and regardless of the > order that are bound to the IGB_UIO driver (e.g. using pci_unbind.py)? Since probe is single threaded. The discovery order will be constant on the same system. But will change if hardware added/removed. Another future area of work that needs to be addressed is hot plugging devices into a running application. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] 答复: Port-ids and NIC features 2013-08-15 14:57 ` Stephen Hemminger @ 2013-08-15 22:15 ` Marc Sune 2013-08-15 23:31 ` Stephen Hemminger 0 siblings, 1 reply; 5+ messages in thread From: Marc Sune @ 2013-08-15 22:15 UTC (permalink / raw) To: Stephen Hemminger; +Cc: dev 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. A general and elegant solution, IMHO would be to add to this in the info of the NIC, probably to struct rte_eth_dev_info; something like: enum rte_eth_features { ETH_LINK_100MB_HD = 1 << 0, ETH_LINK_100MB_FD = 1 << 1, ETH_LINK_1000MB_HD = 1 << 2, ETH_LINK_1000MB_FD = 1 << 3, ETH_LINK_10000MB_HD = 1 << 4, ETH_LINK_10000MB_FD = 1 << 5, //More features to be added here: }; struct rte_eth_dev_info { //... uint32_t capabilities; //Bitmap of enum rte_eth_features (could be also an uint64_t) }; I assume this informations are very easily gathered by the driver itself, since it knows the exact NIC model and capabilities. 2) Are the ids determined when the NICs are being binded to the DPDK driver, or when the IGB_UIO driver is insmoded? If it is the former, then the ids won't be consistent across reboots or binding order, which is not very desirable (IMHO), and actually is going to cause some problems in our application. Best marc On 15/08/13 16:57, Stephen Hemminger wrote: > On Thu, 15 Aug 2013 09:51:00 +0800 > 安宏奎 <anhk_@126.com> wrote: > >> For the question one, maybe you can detect it before binding to igb_uio >> >> >> -----邮件原件----- >> 发件人: dev-bounces@dpdk.org [mailto:dev-bounces@dpdk.org] 代表 Marc Sune >> 发送时间: 2013年8月14日 16:57 >> 收件人: dev@dpdk.org >> 主题: [dpdk-dev] Port-ids and NIC features >> >> Dear all, >> >> Two quick questions: >> >> 1) Is there a way to get the features available in the NIC? In particular, I >> cannot see a way to retrieve the *maximum speed* of the card and I need to >> determine whether is a FE, GE or 10GE card. > Not at present. You need to look at the information in rte_pci_device > for the ethernet (see rte_eth_dev_info) and then do your own matching > against ID and features. > > As DPDK evolves more of the hardware features need to be abstracted > to allow applications to be build once and run on varying hardware. > IMHO some of the low level features like read/write thresholds really > shouldn't be exposed through the API. Setting them correctly depends > too much on the underlying hardware, chip version, and driver and really > shouldn't be something the application writer has to worry about. > > >> 2) For a certain number of NICs installed in the system and bound to the >> IGB_UIO driver, is it safe to assume that the association phyisical port <-> >> port_id will always be the same? Even after reboot, and regardless of the >> order that are bound to the IGB_UIO driver (e.g. using pci_unbind.py)? > Since probe is single threaded. The discovery order will be constant > on the same system. But will change if hardware added/removed. > > Another future area of work that needs to be addressed is hot plugging > devices into a running application. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] 答复: Port-ids and NIC features 2013-08-15 22:15 ` Marc Sune @ 2013-08-15 23:31 ` Stephen Hemminger 0 siblings, 0 replies; 5+ messages in thread From: Stephen Hemminger @ 2013-08-15 23:31 UTC (permalink / raw) To: Marc Sune; +Cc: dev 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). ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-08-15 23:30 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-08-14 8:56 [dpdk-dev] Port-ids and NIC features Marc Sune 2013-08-15 1:51 ` [dpdk-dev] 答复: " 安宏奎 2013-08-15 14:57 ` Stephen Hemminger 2013-08-15 22:15 ` Marc Sune 2013-08-15 23:31 ` Stephen Hemminger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).