On 6/4/15, 7:58 AM, "Stephen Hemminger" <stephen at networkplumber.org> wrote:
>On Wed, 3 Jun 2015 02:09:39 +0000 >"Andrew Harvey (agh)" <agh at cisco.com> wrote: > >> I believe that their is value in this interface for software stacks not >> based on Linux being moved toward DPDK that need simple operations like >> getting the mac address. Some of these stacks have a dearth of >>resources >> available and dedicating a core/thread to KNI to get/set a mac address >> is considered excessive. There are also issues with 32/64 bit kernel >> integration >> using KNI. If the ethtool interface is not the correct interface then >> please help me >> understand what should/could have been used. If ethtool is considered >>'old >> and clunky? >> Stephen's and your input would be valuable in designing another >>interface >> with >> similar properties. The use-case is pretty simple and there is no plans >> for moving >> anything back into the kernel on the contrary its the complete opposite. >> >> ? Andy > >We have DPDK API's to do this, and any added wrappers make it bigger. >I don't see why calling your ethtool API is better than calling >rte_eth* API. > >If there is a missing functionality in the rte_ethXXX api's for an >application then add that. For example: rte_eth_mac_addr_get() I am getting somewhat confused by your latest comments. Your first email (referenced below) looked really positive and I found your suggestions useful. Your latest post appears to contradict this and now the interface was there all the time. The wrapper fa?ade provided by the ethtool library provide a clean separation of concerns and will allow people to migrate from not only KNI but in our case from a legacy system. If a software stack has requirements to work with multiple IO abstractions then the ethtool approach is attractive. I would speculate that many other stacks moving towards dpdk will have similar issues. Summarizing, for our use-cases the ethtool interface facilitated our adoption to dpdk while allowing us to support our legacy IO abstractions. ? Andy http://dpdk.org/ml/archives/dev/2015-May/018408.html (original email) http://dpdk.org/ml/archives/dev/2014-June/003005.html (ethtool request)