From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by dpdk.org (Postfix) with ESMTP id E10555A06 for ; Fri, 5 Jun 2015 12:47:39 +0200 (CEST) Received: by wifx6 with SMTP id x6so16294699wif.0 for ; Fri, 05 Jun 2015 03:47:39 -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=jN8xmcJUu27ylO0DHu/JqcM6oGoURfEx5MfAbVXOkko=; b=dbO7XwAIl/zG1HMjdN9qqdZM1fRPwvrwKBRexVZzNByYhch7qM9xOvaExlGHpf1lNm 5Yrd602DRQIY2Hr7mbgMI63QgXFINnfLhbqSNv0oGYHIQKVG9NQYo+MWN+BtB72LUESf /aW8Ds3DfX21Wxno0Vr3kXIa6QqeeTjTpW26I1XapzDg+qYC4gkftjnqLpNipzd/tot4 xRd0rTuirCXVnAJw9eTyQIwIE4P0jVZoq1Et59qCFjF7Dia6Vm1IhvygQ8DFebUaVtOd c2gU/bZFKg10L78tfOuF/F3d1EobUYgVEQP2JthG5ODOuknOL14EdF+0Uit/0boXoQBS G2tQ== X-Gm-Message-State: ALoCoQlczIjUGNyJRwk7Um/Mc+9d4wj18h76JDmIlYF4mOHQThDq3kKfvxgPYgPVNdYvRlRiPaF4 X-Received: by 10.194.85.163 with SMTP id i3mr5160414wjz.141.1433501259714; Fri, 05 Jun 2015 03:47:39 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id pf4sm5320075wjb.23.2015.06.05.03.47.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2015 03:47:38 -0700 (PDT) From: Thomas Monjalon To: "Andrew Harvey (agh)" Date: Fri, 05 Jun 2015 12:46:47 +0200 Message-ID: <18146131.KjMWrd7xqb@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> <20150604075810.0c087b21@urahara> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Cc: dev@dpdk.org, "Wang, Liang-min" 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: Fri, 05 Jun 2015 10:47:40 -0000 2015-06-04 22:10, Andrew Harvey: > On 6/4/15, 7:58 AM, "Stephen Hemminger" = wrote: > >"Andrew Harvey (agh)" wrote: > >> I believe that their is value in this interface for software stack= s 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 add= ress > >> is considered excessive. There are also issues with 32/64 bit kern= el > >> 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 conside= red > >>'old > >> and clunky=C2=B9 > >> 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 opp= osite. > >>=20 > >> =E2=80=B9 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() >=20 > I am getting somewhat confused by your latest comments. Your first e= mail > (referenced below) looked really positive and I found your suggestion= s > useful. Your latest post appears to contradict this and now the inter= face > was there all the time. The wrapper fa=C3=A7ade provided by the etht= ool > 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. >=20 > Summarizing, for our use-cases the ethtool interface facilitated our > adoption to dpdk while allowing us to support our legacy IO abstracti= ons. Stephen and me say the same thing about using the ethdev API. 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