From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com
 [209.85.212.169]) by dpdk.org (Postfix) with ESMTP id D75E3C33A
 for <dev@dpdk.org>; Tue,  2 Jun 2015 18:03:38 +0200 (CEST)
Received: by wizo1 with SMTP id o1so150603705wiz.1
 for <dev@dpdk.org>; Tue, 02 Jun 2015 09:03:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:organization
 :user-agent:in-reply-to:references:mime-version
 :content-transfer-encoding:content-type;
 bh=ejx4DqXevI45636nDq72DOOE38AIqxR8PJajnQlhtsk=;
 b=eg6lGj+M2kioydLVtL/6kpv9LJLcLR5SeAoVKlKD/td5yDd2BI6frBbcpmYlHujMj8
 IM8jRbOKBGBjE7kNxspTPZEdSDnSBLlP/Tvk2+zopPCgdq0XKo40DCEf+GA9zWNE9cAS
 fsBr/0PH7ZZKJGlSrDgKdCfjxgkqBqI9Me6IfbrMPGKKlxriE7BXEa6phWZWKuxKeKlr
 iF+zxprE3Ut9M6y+PIRItMg0TlVd6jJdU1f7LUXZcIvO89Um9KGuvTBjAV3OdjveXeyF
 SxlSVGUei8SUXIOJ1zGTF3PKaopBsoNB/pUiwP+TXsFSX3s+MuzCG9lfh5s/rTpOhoUk
 CO6w==
X-Gm-Message-State: ALoCoQmRAMdDs9vWrWa2/IGQpeaLxLqTeDnu1rvwIMElDRWyPgDleprjsY6TGFiZvFpaIpFUd4d6
X-Received: by 10.180.39.147 with SMTP id p19mr32351370wik.15.1433261018755;
 Tue, 02 Jun 2015 09:03:38 -0700 (PDT)
Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136])
 by mx.google.com with ESMTPSA id f8sm22302975wiy.7.2015.06.02.09.03.37
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 02 Jun 2015 09:03:37 -0700 (PDT)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Wang, Liang-min" <liang-min.wang@intel.com>
Date: Tue, 02 Jun 2015 18:02:50 +0200
Message-ID: <38737329.jBeOYmBEyN@xps13>
Organization: 6WIND
User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; )
In-Reply-To: <B6CB929FEBC10D4FAC4BCA7EF2298E2571765AC2@FMSMSX110.amr.corp.intel.com>
References: <1432927612-12244-1-git-send-email-liang-min.wang@intel.com>
 <3076202.B6CvAKP4DR@xps13>
 <B6CB929FEBC10D4FAC4BCA7EF2298E2571765AC2@FMSMSX110.amr.corp.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide
	ethtool-alike APIs
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2015 16:03:39 -0000

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?