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

David Harton (dharton) dharton at cisco.com
Wed Jun 3 03:00:07 CEST 2015


Hi Thomas,

I think Larry explains things pretty clearly below.

A new application facing API is bring provided that avoids reusing kernel specific types and structs or dipping into the kernel itself.  It also clearly separates the user space API from driver related functions/types.

We do want to limit dipping into the kernel for performance reasons.

I hope this helps,
Dave

> -----Original Message-----
> From: Wang, Liang-min [mailto:liang-min.wang at intel.com]
> Sent: Tuesday, June 02, 2015 4:56 PM
> To: Thomas Monjalon
> Cc: dev at dpdk.org; David Harton (dharton)
> Subject: RE: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide
> ethtool-alike APIs
> 
> >I have the feeling we are not progressing in this discussion.
> >Please bring new explanations or I'll give up.
> >David Harton already acked it so maybe he could explain why it is useful.
> >
> >Comments below
> >
> >2015-06-02 17:06, Wang, Liang-min:
> >> >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?
> >
> >They are not ethtool/netdev ops but fake ones.
> >In linux:
> >	int dev_set_mtu(struct net_device *dev, int new_mtu) In dpdk:
> >	int rte_ethtool_net_change_mtu(uint8_t port_id, int mtu); So yes,
> I'm opposed to add an API which is neither ethdev, neither ethtool.
> >But I may be missing an obvious justification.
> 
> So, the design purposely stays away from struct net_device to avoid
> carrying kernel states. We consciously choose port in place of net_device.
> The kni already provides ethtool for kernel space code, this interface is
> designed for user-space application (fast-path comparing to kni).
> 
> >> 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?
> >
> >Already answered above
> >>
> >>     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?
> >
> >No, it's better as a separate library.
> >
> >>     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
> >
> >Do you mean it would help migrating some code from kernel space to dpdk?
> >How it would help since the functions and data are different from the
> kernel ones?
> 
> For application that was designed based upon kernel-space ethtool-op and
> net-device-op, the user-space APIs provide a path for quick integration.
> 
> >> BTW, as my reply to Steve's comment, more ops are on their way. This
> patch is to open up the interface.
> >
> >Currently they are only some one-liners plus ethtool_drvinfo formatting
> so there is no real benefit.
> >Why not wait to have more ops implemented?
> Due to amount of code change, I was advised to put into separate release
> and started with APIs that only requires minor changes on ethdev.
> The rest of API requires changes on NIC pmd driver to support ops that are
> not currently supported.


More information about the dev mailing list