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

[Wang, Liang-min]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, June 05, 2015 6:47 AM
> To: Andrew Harvey (agh)
> Cc: Stephen Hemminger; Wang, Liang-min; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide
> ethtool-alike APIs
> 
> 2015-06-04 22:10, Andrew Harvey:
> > On 6/4/15, 7:58 AM, "Stephen Hemminger"
> <stephen at networkplumber.org> wrote:
> > >"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.
> 
> Stephen and me say the same thing about using the ethdev API.
> We don't understand why using a fake ethtool lib would be easier.
> Though you are saying it "facilitated [your] adoption to dpdk".
> Please could you explain why using an ethtool-like API is easier than using
> the existing ethdev API?
> In any case, you have to develop a specific backend for DPDK (rte_ethtool
> would be also DPDK-specific).

As described earlier in this patch comment reply, there are other ethtool ops that have been implemented.
Those ops includes set/get eeprom, set/get pauseparam, set/get ringparam which are not available in the exiting ethdev library.
For this release, we focus on releasing some basic functions (btw, mac_addr_set is not available but is covered by this patch).
The key reason that this set of library is not released as part of ethdev is the ethtool API dependency on kernel include file.
To faithfully carry the ethtool ops and net dev ops API parameters, the ethtool APIs are designed to follow the original definition except avoiding carry kernel states.
With that, to support ethtool APIs faithfully, we need to include <linux/ethtool.h>. 
As suggested by many DPDK veterans including Thomas (indicated over your reply), you would prefer these APIs in a separate library.

> 
> It seems you already started to use such an ethtool implementation.
> Please note that our goal is not to prevent Cisco from upstreaming (evidence
> with enic driver integration) but we want to guide you, and others having the
> same needs, to the best solution for everybody.
> That's why we need to understand what we (or you) are missing.
> Maybe that it would be clearer with some code examples (which would go in
> the lib documentation if any).
> 
> Thanks