From: "O'Driscoll, Tim" <tim.o'driscoll@intel.com>
To: "Andrew Harvey (agh)" <agh@cisco.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>,
"Wang, Liang-min" <liang-min.wang@intel.com>,
Stephen Hemminger <stephen@networkplumber.org>,
"David Harton (dharton)" <dharton@cisco.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide ethtool-alike APIs
Date: Thu, 4 Jun 2015 14:25:55 +0000 [thread overview]
Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D55BB3@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <D193AD6E.33EF5%agh@cisco.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Andrew Harvey (agh)
> Sent: Wednesday, June 3, 2015 3:10 AM
> To: Thomas Monjalon; Wang, Liang-min
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide
> ethtool-alike APIs
>
> 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
Stephen, Thomas: I think it was the two of you that originally questioned the justification for including this change. Now that Andy and Dave Harton have clarified, does this resolve your concerns or do you still have questions? I just want to make sure that we reach a timely conclusion on this.
Tim
>
>
> On 6/2/15, 1:37 PM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:
>
> >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@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.
> >
> >> 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?
> >
> >> 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?
> >
next prev parent reply other threads:[~2015-06-04 14:25 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-29 19:26 [dpdk-dev] [PATCH 0/2] User-space Ethtool Liang-Min Larry Wang
2015-05-29 19:26 ` [dpdk-dev] [PATCH 1/2] ethdev: add api to set default mac address Liang-Min Larry Wang
2015-06-02 10:52 ` Ananyev, Konstantin
2015-06-02 12:23 ` Thomas Monjalon
2015-06-02 14:51 ` Stephen Hemminger
2015-06-02 15:07 ` Wang, Liang-min
2015-06-02 12:23 ` Wang, Liang-min
2015-06-02 13:10 ` Ananyev, Konstantin
2015-05-29 19:26 ` [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide ethtool-alike APIs Liang-Min Larry Wang
2015-06-02 12:38 ` Thomas Monjalon
2015-06-02 13:15 ` Wang, Liang-min
2015-06-02 14:32 ` Thomas Monjalon
2015-06-02 15:47 ` Wang, Liang-min
2015-06-02 16:02 ` Thomas Monjalon
2015-06-02 17:06 ` Wang, Liang-min
2015-06-02 20:37 ` Thomas Monjalon
2015-06-02 20:56 ` Wang, Liang-min
2015-06-03 1:00 ` David Harton (dharton)
2015-06-03 2:09 ` Andrew Harvey (agh)
2015-06-04 14:25 ` O'Driscoll, Tim [this message]
2015-06-04 14:58 ` Stephen Hemminger
2015-06-04 22:10 ` Andrew Harvey (agh)
2015-06-05 10:46 ` Thomas Monjalon
2015-06-05 11:25 ` Wang, Liang-min
2015-06-05 12:47 ` Bruce Richardson
2015-06-05 17:24 ` Andrew Harvey (agh)
2015-06-05 21:03 ` Thomas Monjalon
2015-06-05 13:40 ` Thomas Monjalon
2015-06-05 14:20 ` Wang, Liang-min
2015-06-05 16:07 ` Andrew Harvey (agh)
2015-06-05 20:57 ` Thomas Monjalon
-- strict thread matches above, loose matches on Subject: below --
2015-05-30 0:37 [dpdk-dev] [PATCH 0/2] User-space Ethtool Liang-Min Larry Wang
2015-05-30 0:37 ` [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide ethtool-alike APIs Liang-Min Larry Wang
2015-05-30 15:48 ` Stephen Hemminger
2015-05-30 16:16 ` Wang, Liang-min
2015-05-30 19:26 ` Stephen Hemminger
2015-05-30 19:40 ` Wang, Liang-min
2015-05-31 16:48 ` Stephen Hemminger
2015-05-31 17:30 ` Wang, Liang-min
2015-05-31 18:31 ` Wang, Liang-min
2015-06-01 12:42 ` David Harton (dharton)
2015-05-29 13:15 [dpdk-dev] [PATCH 0/2] User-space Ethtool Liang-Min Larry Wang
2015-05-29 13:15 ` [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide ethtool-alike APIs Liang-Min Larry Wang
2015-05-29 15:22 ` Stephen Hemminger
2015-05-29 18:17 ` Wang, Liang-min
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26FA93C7ED1EAA44AB77D62FBE1D27BA54D55BB3@IRSMSX102.ger.corp.intel.com \
--to=tim.o'driscoll@intel.com \
--cc=agh@cisco.com \
--cc=dev@dpdk.org \
--cc=dharton@cisco.com \
--cc=liang-min.wang@intel.com \
--cc=stephen@networkplumber.org \
--cc=thomas.monjalon@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).