>>On Sat, 30 May 2015 19:40:46 +0000 >>"Wang, Liang-min" <liang-min.wang at intel.com> wrote: >> >>> > >>On Sat, 30 May 2015 16:16:01 +0000 > >>"Wang, Liang-min" <liang-min.wang at intel.com> wrote: > >> > >> >>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. > >>> > >>>But there is no open/close/start in ethtool in kernel. > >>>Anyway ethtool is currently on the disfavored list from kernel developers. > >>>What about netlink or something better? > >>> > >>>Remember each new API creates more long term compatiablity and ABI issues. > >>>So I am against introducing any new API that does the same thing as > >>>existing API's. > >> >>> Just to clarify APIs supported by this ethtool api: there are >>> net_open > >>and net_stop and no net_start. Both functions are put in place to > >>support net_device_ops::ndo_open and net_device_ops::ndo_close as > >>defined in linux/netdevice.h >> >> >>I get the feeling there is some use case you are not telling the list about. >>What kind of application would use this api only. Why or how would DPDK >>application be involved in net_device_ops. If you are planning on putting >>DPDK in the kernel there are lots of other issues >>including kernel ABI >>stability and licensing that need to be dealt with. > >(I'm manually adding ">" through my email, outlook, to make my reply. I >apology if I make any mistake on adding ">" in wrong place) No, we don't plan >to put DPDK into kernel space, and this patch has >nothing to do with >bifurcated driver that was announced for DPDK 2.0 then got scrubbed (or >deferred). In contrary, the entire ethtool API (more support is coming) is >designed to assist applications that >were designed based upon kernel ethtool >to migrate into user-space driver based DPDK libraries. Being said that, as >you are aware the kernel version of ndo_open/ndo_close is more than just start >and >stop device. The initial implementation is to provide minimum >functionality (strip off all the kernel related state management). In the >future release (we need comments like yours), we will continue >make >improvement. So this new API can be another alternative for applications to >run device management.
Just to clarify my last reply: when I said "... based upon kernel ethtool to migrate ...", I was referring to both ethtool and net_device_op.
