>On Fri, 29 May 2015 20:37:56 -0400 >Liang-Min Larry Wang <liang-min.wang at intel.com> wrote: > >> adding a new library based upon ethdev APIs to provide API's that bear >> the same functionality as ethtool_ops (linux/ethtool.h) and > >net_device_ops (linux/netdevice.h).
>The API's for ethtool like things are valuable, but please contain it more. > >I think you should contain this to only those things which are in the original >Linux ethtool. Adding yet another layer that calls DPDK for open/close/start >stop just adds more layers with out providing any value. > >The ones I would keep: > get_driverinfo > get_link > >The ones I would add: > cmd - for speed/duplex negotiation > eeprom - for eeprom access > eee - for energy awareness > coalesce - for packet coalescing > ringparam - to allow changing ring parameters > (existing rx config model is limiting) > pauseparam - existing flow control in DPDK is mess > gstrings/stats - map to XSTATS > test - for offline tests > dump - for register dump > features - control offload features > perm_addr - base mac address The design decision is to keep ethdev as THE interface for all the external API, so ethtool APIs are designed based upon ethdev API. At the meantime, the ethtool APIs are designed to enable users to migrate designs based upon kernel-space ethtool. The open/close/start are put in place to enable quick migration. As for the suggestion, eeprom/ringparam/pauseparam/register-dump are on their way for latter release. For other ops, I will take the feedback for future planning.
