From: "Andrew Harvey (agh)" <agh@cisco.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Wang, Liang-min" <liang-min.wang@intel.com>
Subject: Re: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide ethtool-alike APIs
Date: Fri, 5 Jun 2015 16:07:53 +0000 [thread overview]
Message-ID: <D197159C.3437C%agh@cisco.com> (raw)
In-Reply-To: <18146131.KjMWrd7xqb@xps13>
On 6/5/15, 3:46 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:
>2015-06-04 22:10, Andrew Harvey:
>> On 6/4/15, 7:58 AM, "Stephen Hemminger" <stephen@networkplumber.org>
>>wrote:
>> >"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.
>
>Stephen and me say the same thing about using the ethdev API.
And your would have a point would be valid if dpdk were available to every
interface we support (it is not) and on every processor architecture that
we support (it is not) and every OS we support (it is not). So to
minimize entropy in the code why not leave the client code the same
ioctl(fd, …) and hide the implementation
detail in a wrapper library. We have a large legacy code base to move
forward and sprinkling special interest code like rte_xxx throughout every
client we have is not appropriate at this time.
>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).
>
>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
next prev parent reply other threads:[~2015-06-05 16:07 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
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) [this message]
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=D197159C.3437C%agh@cisco.com \
--to=agh@cisco.com \
--cc=dev@dpdk.org \
--cc=liang-min.wang@intel.com \
--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).