From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f178.google.com (mail-wr0-f178.google.com [209.85.128.178]) by dpdk.org (Postfix) with ESMTP id 47F7811DE for ; Fri, 17 Mar 2017 09:02:51 +0100 (CET) Received: by mail-wr0-f178.google.com with SMTP id u108so46633683wrb.3 for ; Fri, 17 Mar 2017 01:02:51 -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=iLkinEP01li2HYLxBSWVK1poXrRw24jjcq+wd8SL5oU=; b=sMCo7vYoDSOEcIb95TS3hu6IHglLzZQ3DI5NuMkEGfU2lAfZeB6QaZvWwNl3CYpEfX 09V/vAEwUvebS06POh5q5lXr7LG9wjdRKwDiSAYNzbf3dyhgSNYyeNaaxpPnurpy6BoD qxYdwms/7r0ZuKPXSNT6kD5bL+am1wCzPnwK45jjXjfAccdPbo9vzsHvYeVtAAwlmGzs TvQ4oyBSlkI1jQewKHa1vdzuBsJbn1iaZ/aLBcX+rf5OKJ8U2MBptP1b0bsl541bDzkT 9/CpGMS9CzmbAs2Ch6W+SIg5q9ao8XX8jEYLCiewV17joMHIEI950onbomxMzpJyjzER 9hXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=iLkinEP01li2HYLxBSWVK1poXrRw24jjcq+wd8SL5oU=; b=FuVQ9QV2Zt/a/4x9O2dXJZWevA05gKy3RfL4/P/098TDjlzkkmA6qrY8gdPxrMFwKc PaMvXuk/DUkptYpN7s5xl7fZE+kW2UaiWML+ePln7wJaQdMRBPiN3Wl4Es3nIhNDyjtg J6/VNcJggo9oqesI01qLtHHcLXrEIXW3rNpvdlqZEAZ3jBj3bbspha5Oaz7KsTk926Gg NM3hinXlL/WyCWkL/gXMM8N5F+fSNgJ/ypVCi7TE4eSpIOq178BiMd6OzwshLEPIAguG FoQnZ8yN4w+lVusW3bpgH3mgfJmN1qiFLy4SHJoXY6GSWw6L73NxvRTKLoe6G5rWgAEQ 0qRw== X-Gm-Message-State: AFeK/H0Pg4/lhuE+c2/A/zqxvnj1orJGsJ3c9wSzatdQigQFgiF3XSPJLfN7GzYBId4DTw9i X-Received: by 10.223.175.81 with SMTP id z75mr11614153wrc.3.1489737770905; Fri, 17 Mar 2017 01:02:50 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id b63sm9014102wrd.15.2017.03.17.01.02.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 01:02:50 -0700 (PDT) From: Thomas Monjalon To: "Zhang, Helin" Cc: "Zhang, Qi Z" , techboard@dpdk.org, dev@dpdk.org, "Wu, Jingjing" , "Yigit, Ferruh" Date: Fri, 17 Mar 2017 09:02:49 +0100 Message-ID: <6289634.vIM6mFEBdc@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <1487874421-11934-1-git-send-email-qi.z.zhang@intel.com> <2062537.uIRGRt8aVp@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] net/i40e: enable statistic reset for VF X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 08:02:51 -0000 2017-03-17 03:28, Zhang, Helin: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2017-02-23 13:27, Qi Zhang: > > > static void > > > +i40evf_dev_stats_reset(struct rte_eth_dev *dev) { > > > + struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data- > > >dev_private); > > > + /* only DPDK PF support this */ > > > + if (vf->version_major == I40E_DPDK_VERSION_MAJOR) { > > > + if (i40evf_reset_statistics(dev)) > > > + PMD_DRV_LOG(ERR, "Reset statistics failed"); > > > + } > > > +} > > > > One more SR-IOV feature not supported with a Linux PF. > > The basic stats feature must be marked as partially supported in > > doc/guides/nics/features/i40e_vf.ini > > See also this email: > > http://dpdk.org/ml/archives/dev/2017-March/060063.html > > > > I wonder whether we should allow such divergence between PF > > implementations. Intel committed to avoid such fragmentation and keep the > > SR-IOV messaging standard but it does not happen. > > It is said that we must allow fast innovation in DPDK space. > > I agree but we should also target a good usability of the VF drivers, allowing to > > replace the PF implementations as needed. > > Hi Thomas > > I think I need to clarify a little bit here. > I think we will try our best, but I don't think we can commit. As they are on > totally different community, and of cause code repositories. > > > > > Here is my suggestion: let's accept a VF feature only if the PF support is > > submitted to both dpdk.org and kernel.org mailing lists. > > I ask to add this topic to the next techboard meeting. > > Sorry, technically I disagree with this suggestion, as I don't understand why! > I was told DPDK is not Linux, and Linux is not DPDK. Why we want to add this > dependency on Linux PF host driver? And why just on PF/VF driver feature only? > I think if we can have any good innovative idea on DPDK first, why not just > have it on DPDK? Then Linux or even other OS/community/Company can learn > from DPDK and develop their own. It is really a general problem. Here you are adding a feature in a VF driver. But it does not work with some PF drivers. We have the same problem when adding a feature which does not work on BSD or on a CPU architecture. Generally speaking, we have a usability issue when a feature works only with a given environment. And it is worst in the SR-IOV case because a VM can migrate from an hypervisor (with a given PF) to another (and different) one.