From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id DDEDF69FC for ; Wed, 11 Jan 2017 12:03:45 +0100 (CET) Received: by mail-wm0-f49.google.com with SMTP id c85so154733573wmi.1 for ; Wed, 11 Jan 2017 03:03:45 -0800 (PST) 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=rtn4BV7tQ7WNJJQrg9hN93/+S2xP7qbP0WdK7ikrDzo=; b=TcDpDPwx3i+y8zSqEntZtVqT9RVL1eU7ISX7q7f2UdbUdmxRr39/xMm3vSMMOxJOiZ pmAYabTun+CRwdw7TkYOTOJJwgTAXsRuXIQvI+GeJsX2V5eRxBvfJTwhcEhVPm4qV4bL qh9AUQ+2eWukhLN72+uAWCmZO7/NPuqaQcgtnFeJbjAoNNIvecp3HpM6L7FgqjkfxzET ojvHL2viwpug07kBZy3NlK9dNe2VMwxnlW0fKYerdSrY4i2wr6S9qVUeBsgefxB4fXyJ 5YvjOsIBJLp8sQakrXTVa14SV+tfoOW6aGon5ArYq/n1XvPhjWRTNYngte44JfVrYtdR UsEQ== 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=rtn4BV7tQ7WNJJQrg9hN93/+S2xP7qbP0WdK7ikrDzo=; b=GdvnQbngcFei00hGzwpiLmiTRY8Lkh9JxvCND/UiKCR/1aye8SrKJ3tK3GFxvDcNFT XshiCl65avXm33APGLMFdQv+DVv4LhgCSr8Bqbmf4Bc+h0Y75Ef3fWE4Wq9oZ3DvnnyG FhE+1LRU3z4ORYrjfrIgVJgOCK6amWiMrqvquRA0Wx2/hYOTnZEgVOzOCglSL36o+qAB TAYypMfsQkJ4He6pDil6X8cE7ITYwnX6VFFqSKZ5i+fikBnkBfTE+PunyqqLQPSKTb+S 58MW1K0pFUTLciWmCg8EIWj9DK6X1AuoNtNfjwAB3t3RV4Kik7YhNNaQQ38EkWKLpDKk 1hrA== X-Gm-Message-State: AIkVDXKUVqCiwjKN0kv9DczF01Sndf3IIddyt82pjHU4dgsrCKjQP/+NlrWaFngVYAVUbVFg X-Received: by 10.28.156.151 with SMTP id f145mr4963284wme.8.1484132625590; Wed, 11 Jan 2017 03:03:45 -0800 (PST) Received: from [100.104.192.155] ([80.215.175.94]) by smtp.gmail.com with ESMTPSA id 4sm7861648wjz.1.2017.01.11.03.03.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 03:03:44 -0800 (PST) From: Vincent Jardin To: "JOSHI, KAUSTUBH (KAUSTUBH)" CC: "Zhang, Helin" , "Lu, Wenzhuo" , , "DANIELS, EDWARD S (EDWARD)" , "ZELEZNIAK, ALEX" Date: Wed, 11 Jan 2017 12:03:42 +0100 Message-ID: <1598d329eb0.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> In-Reply-To: References: <1480637533-37425-1-git-send-email-wenzhuo.lu@intel.com> <1484032580-60134-1-git-send-email-wenzhuo.lu@intel.com> <1598a0c7f80.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> User-Agent: AquaMail/1.7.1-88 (build: 100700100) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v8 00/25] Support VFD on i40e 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: Wed, 11 Jan 2017 11:03:46 -0000 Please can you list the gaps of the Kernel API? Thank you, Vincent Le 11 janvier 2017 3:59:45 AM "JOSHI, KAUSTUBH (KAUSTUBH)" a écrit : > Hi Vincent, > > Greetings! Jumping into this debate a bit late, but let me share our point > of view based on how we are using this code within AT&T for our NFV cloud. > > Actually, we first started with trying to do the configuration within the > kernel drivers as you suggest, but quickly realized that besides the > practical problem of kernel upstreaming being a much more arduous road > (which can be overcome), the bigger problem was that there is no > standardization in the configuration interfaces for the NICs in the kernel > community. So different drivers do things differently and expose different > settings, and no forum exists to drive towards such standardization. This > was leading to vendors have to maintain patched versions of drivers for > doing PF configuration, which is not a desirable situation. > > So, to build a portable (to multiple NICs) SRIOV VF manager like VFd, DPDK > seemed like a good a forum with some hope for driving towards a standard > set of interfaces and without having to worry about a lot of legacy baggage > and old hardware. Especially since DPDK already takes on the role of > configuring NICs for the data plane functions anyway - both PF and VF > drivers will have to be included for data plane usage anyway - we viewed > that adding VF config options will not cause any forking, but simply flush > out the DPDK drivers and their interfaces to be more complete. These APIs > could be optional, so new vendors aren’t obligated to add them. > > Furthermore, allowing VF config using the DPDK PF driver also has the side > benefit of allowing a complete SRIOV system (both VF and PF) to be built > entirely with DPDK, also making version alignment easier. > > We started with Niantic, which already had PF and VF drivers, and things > have worked out very well with it. However, we would like VFd to be a > multi-NIC vendor agnostic VF management tool, which is why we’ve been > asking for making the PF config APIs richer. > > Regards > > KJ > > >> On Jan 10, 2017, at 3:23 PM, Vincent Jardin wrote: >> >> Nope. First one needs to assess if DPDK should be intensively used to >> become a PF knowing Linux can do the jobs. Linux kernel community does not >> like the forking of Kernel drivers, I tend to agree that we should not keep >> duplicating options that can be solved with the Linux kernel. >> >> Best regards, >> Vincent >> >> >