Re: [PATCH 2/2] ethtool: add new library to provide ethtool-alike APIs

["Andrew Harvey (agh)" <agh@cisco.com>]

On 6/4/15, 7:58 AM, "Stephen Hemminger" <stephen@networkplumber.org> wrote:

>On Wed, 3 Jun 2015 02:09:39 +0000
>"Andrew Harvey (agh)" <agh@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)