From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 11ED8D462 for ; Fri, 17 Mar 2017 21:14:46 +0100 (CET) Received: by mail-wm0-f41.google.com with SMTP id n11so24332278wma.0 for ; Fri, 17 Mar 2017 13:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:date:message-id:in-reply-to:references:user-agent :subject:mime-version:content-transfer-encoding; bh=ozARF6npbON9bxOpBBxY9B6eI+Y1uu0FtpBM4UKRt3I=; b=Tb+s3nUKRvpdH7KL5fWjkLiVXnK9Pjg6cKZf/hx5QrpJa3VDffgIYRklSBVL2c+bsd nKWSjyRBq52aAuwU0BuI6d5ArTkm1dWgzbCkWxiW70QYxDpuoDqTKQy5fEyVFqtF+jXv tmbjJ4DHetez0JHLlYTI5a1AMLqpqNIBQxR5KHRuIiQv4ct51Kor36e4gKP6hcpIaGsr /tF3E7CaFRRbbQwcUxRgnpdTlr3RYUmYm/07YLtcf3iquXzF9uHMiufXTYJRB02BsXHp cEM06FycVFpSteDG1Al1nOxxuvfEuaWGgmoJT1vyAkrXXcFt9vmhVxLv9q+gqDOrSxhX zJaw== 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:date:message-id:in-reply-to :references:user-agent:subject:mime-version :content-transfer-encoding; bh=ozARF6npbON9bxOpBBxY9B6eI+Y1uu0FtpBM4UKRt3I=; b=sL/CyMSJUeWaQ/AGbfVLk36nRVe1dSWDEYe6cSYenOToovCqEJhAAbWRpoSaN3z2Yl rgQQfsqg/sH2ybwcxyRAPNdyPGl44EAnz28/af4EtwiaQVV/TxkZh2KtaxGpYr08IZd1 K5kDcoe7h//kujk0NyKfmHWK85LUwpxGvVieLCzlNS1nX8+rwvu7pWcO44+B0fL5pFYO znMNVZdsPkaHgIQGJeNtRHl33bs16PfyYClATn/ZxVezJnDz8NojdNhHRBWo4H49hdoF 43Vbj6VLDSrGWFwEEFSOx+aMPxXA8fxYu5gBcv1qK82155k9sAgdqzvx9iU4PiE8kC3S GrVQ== X-Gm-Message-State: AFeK/H11ODOnlju7Da68f7V/552x/Pp1yIYwJ8eDb9/Edz1VW9gAJpbOuEuzzxNjIl/cruI+ X-Received: by 10.28.1.209 with SMTP id 200mr66885wmb.74.1489781685748; Fri, 17 Mar 2017 13:14:45 -0700 (PDT) Received: from [10.228.64.231] ([80.215.93.148]) by smtp.gmail.com with ESMTPSA id l21sm11099471wrl.59.2017.03.17.13.14.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 13:14:44 -0700 (PDT) From: Vincent Jardin To: Thomas Monjalon , "Zhang, Helin" CC: "Zhang, Qi Z" , , , "Wu, Jingjing" , "Yigit, Ferruh" , "Liang, Cunming" , John Fastabend Date: Fri, 17 Mar 2017 21:14:43 +0100 Message-ID: <15adde87338.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> In-Reply-To: <2542450.7LGoSD6xkf@xps13> References: <1487874421-11934-1-git-send-email-qi.z.zhang@intel.com> <6289634.vIM6mFEBdc@xps13> <2542450.7LGoSD6xkf@xps13> User-Agent: AquaMail/1.8.2-216 (build: 100800200) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit 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 20:14:46 -0000 Le 17 mars 2017 11:15:22 AM Thomas Monjalon a écrit : > 2017-03-17 09:45, Zhang, Helin: >>From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] >> >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. > > What prevent you from submitting your code to the kernel community? > Note that your statement does not respect the agreed policy: > http://dpdk.org/ml/archives/dev/2017-January/055224.html > http://dpdk.org/doc/guides/contributing/design.html#pf-and-vf-considerations > >> >> > 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. >> >> Yes, I understood that's the reality and the issue. But I don't think we >> can address it with your suggestion. >> Linux is just one of the OS, as you said, FreeBSD, Windows, VMWare, ... > > I am talking about migration from a KVM to another one. > So BSD, Windows and VMware are irrelevant. > >> I'd suggest to start another discussion on the tech board to solve that >> problem, but not limit >> adding new features. They are different topics and things, based on my >> understanding. > > Helin, you just want to add your new code and hide issues. > You don't even bother to document the limitations or the partial support > as I have suggested earlier. > As a maintainer, I have to check the quality and the usability. > I can tell you that I stack the promises "I will fix it later" and > we are still waiting for a lot of them. > That's why, even if you think it is not related, we need sometimes > to block things until they are properly done and completed. Please, can you bring it to the next tech board? This dispersion of VF/PF make the DPDK unusable into open products with many parties since behavior becomes VF/PF specific. Thank you,