From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 267399AD8 for ; Tue, 2 Jun 2015 22:38:42 +0200 (CEST) Received: by wgez8 with SMTP id z8so149778846wge.0 for ; Tue, 02 Jun 2015 13:38:42 -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=274IcsjqdDCDJiYPmq8OqoYzuai9eqo6qzHOx0GmfHY=; b=HBLQ1Yz7OKaSoslQ21ZiHLU4sBuagDV+u6A/q/MLHHlo9QFImX14SPlsy4urO+5tQ9 +drNGtEaZMTibaP7W1rhf8VgK/12wTDg37bYFbTlOAslHN06QUAOUVQduk4ITpQat56P mHfYSNVx2lFCA72oH7vSwbBI7SH1Bd5gRlRFAOno4Ib66ssdOPlkkiU9DAeF2e474/po w3zXZlOf9M5E1WwzTNEh+d/JQgAQP7zBmVoLsBj0ANXONnzmJuHpvE65itvfyT+A6cqA c+VgY9TMZds4tmaOMG7L3O6WmKMyY0m+/9Mvp5duAZ9zFhhVTwhFtrDNqoI8Ah34gtGT L16A== X-Gm-Message-State: ALoCoQm6qeVoE4ap4+x9igXMaNQNMOGecwro67glNmiquP9RD7rx26xZYj0W2rbXp8apNUUB/z6G X-Received: by 10.194.118.167 with SMTP id kn7mr52733919wjb.113.1433277521972; Tue, 02 Jun 2015 13:38:41 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id m10sm7278205wib.17.2015.06.02.13.38.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2015 13:38:40 -0700 (PDT) From: Thomas Monjalon To: "Wang, Liang-min" Date: Tue, 02 Jun 2015 22:37:52 +0200 Message-ID: <24712227.WkznNjn3ZB@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: References: <1432927612-12244-1-git-send-email-liang-min.wang@intel.com> <38737329.jBeOYmBEyN@xps13> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 20:38:42 -0000 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?