>2015-06-02 15:47, Wang, Liang-min:
>> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> > >>I'm curious to understand how renaming rte_eth_dev_set_mtu() to
>> > >>rte_ethtool_net_change_mtu() will help anyone.
>> >>
>> >> As described, this interface is designed to provide API closely to kernel
>> >> space ethtool ops and net_device_op.
>>
>> >But the application still needs to adapt the code to call rte_* functions.
>> >So changing to rte_ethtool_net_change_mtu is equivalent to change to the
>> >existing rte_eth_dev_set_mtu. I don't see the benefit.
>>
>> The benefit is single interface for users to access. Instead of looking into
>> two different interfaces (ethtool, ether).
>
>Sorry it doesn't help to understand.
>Today, there is an ethdev API. Why adding an ethtool-like API would help?
Need to understand your specific concern. Do you oppose introducing new API to
support ethtool ops and net_device_ops?
Or your concern is on the implementation. If that's latter.
Do you oppose adding a new library to implement ethtool ops and net_device_ops?
If so, are you satisfied with my previous answer on avoiding polluting
ethdev APIs?
If not, do you suggest integrating ethtool APIs into ethdev API?
If not, is your concern on the implementation of common functionality
between ethtool and ethdev APIs?
If so, as explained, it is designed to provide a unified interface to
assist users to migrate from kernel ethtool/net-device-op API to DPDK
BTW, as my reply to Steve's comment, more ops are on their way. This patch is
to open up the interface.
