From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) by dpdk.org (Postfix) with ESMTP id C5291C3AA for ; Wed, 22 Jun 2016 11:18:26 +0200 (CEST) Received: by mail-lf0-f41.google.com with SMTP id l188so67018081lfe.2 for ; Wed, 22 Jun 2016 02:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=RYl7wNpT/C/WSXNJ/USIIGphJwIeEgcjdHEefHMWalc=; b=SiJZwtsVArCcomqSWR++WA6tgIlHTHE6eNtp4Pg18rJK7kXqesabA0L0L7rXau2ARM iO4QcFKs39dTYM6ToPpDIHWqCarTTX3F7FvywXiOv+eP907Ox6YYewZ3Q15qomQ4L826 tMfCmo3NggDdjHrrnUiWB6AyNL/Ym+kOSnPMmsab3DOGJzWZCD5gmd5rjYq1Js8SZppG 4tAA7Tlse6QLTdMyNeA6Wjvn9KN8G7u/8lsxNWxgynTyRiUmrYKod+inWwzVNtb9gSu1 QEvB5pFX19kHMQN18MEnzg1CHokKJgLzbbLtNZyZFkHME+EPPzwYSV08bNoMHyRbx8ZX zp3g== 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:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=RYl7wNpT/C/WSXNJ/USIIGphJwIeEgcjdHEefHMWalc=; b=YuEdnVrj+qiu52g6Tkc4KnbN63RiUX4/zv9EVPfZo6RU0MhvDszaKqfW740Z35CD9K qRMhjpy81V+5JRp5XPn8uPPe/DQTIe9mRxZoC8Vhx41sd9tSLsWbIMpyyex3JMhiTXhr 0Wl6Kdh/9QFL5CjOiPY5Z+gAtZi0SfmG4MPGkVbrkBni94/3Yy65yTTTnV5bFl3Zzfdn hmeNtAMIWRte2EY2uC0cEC7MOzx2ZFPhPX9AZ38kG4HFQ+exLQI5bXKrm4TO0C4AfkIo r2as71OivDGgSj8fmxN1mNHqpxIR1gVYl4CuVaIPOkHGFOudxLHR3OgoMsCMMDC7tmzh 1yGg== X-Gm-Message-State: ALyK8tILav2hxly7YdMTN6QIr8sgjl+us6Xlu6TZtpH3P7Cai6gOzdQ7zItsCTZ+JSCCHhwB X-Received: by 10.194.71.50 with SMTP id r18mr8173378wju.116.1466587105994; Wed, 22 Jun 2016 02:18:25 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id x83sm1737312wmx.9.2016.06.22.02.18.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jun 2016 02:18:23 -0700 (PDT) From: Thomas Monjalon To: "Lu, Wenzhuo" , Jerin Jacob Cc: dev@dpdk.org, "Ananyev, Konstantin" , Stephen Hemminger , "Richardson, Bruce" , "Chen, Jing D" , "Liang, Cunming" , "Wu, Jingjing" , "Zhang, Helin" Date: Wed, 22 Jun 2016 11:18:21 +0200 Message-ID: <6984459.KfxJSr4bsX@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09090348995A@shsmsx102.ccr.corp.intel.com> References: <20160621133041.GA7509@localhost.localdomain> <6749084.arHGZf8DkE@xps13> <6A0DE07E22DDAD4C9103DF62FEBC09090348995A@shsmsx102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support device reset 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: Wed, 22 Jun 2016 09:18:27 -0000 2016-06-22 08:25, Lu, Wenzhuo: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2016-06-22 13:29, Jerin Jacob: > > > Thomas, > > > As a librte_ether maintainer any comments on this? > > > > +1 for adding details and make sure naming is good. > > I don't really need to comment here because I have already done this comment > > earlier: > > http://dpdk.org/ml/archives/dev/2016-June/041845.html > > Thank you for insisting. > I've add some details in this patch set. If it's not enough, please let me know. > And I think this discussion is about what the API name should be like. Actually I think all the existing name is describing what is done by the API not when and where it should be used, like dev_start/stop. You're right, I overlooked it: + * The API will stop the port, clear the rx/tx queues, re-setup the rx/tx + * queues, restart the port. Jerin, which detail do you think is needed? Wenzhuo, why this function is needed? All these actions are already possible independently. When looking at ixgbe implementation, I see: ixgbevf_dev_stats_reset() which is not documented in the API rte_delay_ms(1000); do {} while It looks to be some hacks. If you really need some workarounds to handle some tricky situations, maybe that the API is not detailed enough. > But anyway I'm open for changing the name. Is the name process_reset_intr you prefer? Thanks. Not sure. If you really intend to add a generic reset, maybe rte_eth_dev_reset() is a good name. We just need more justification. After reading the doc, the user can understand it is just a wrapper of existing functions. But it appears in the code that it does more and can help in some situations.