From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Jardin Subject: Re: [PATCH v8 00/25] Support VFD on i40e Date: Wed, 11 Jan 2017 12:03:42 +0100 Message-ID: <1598d329eb0.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> 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> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: "Zhang, Helin" , "Lu, Wenzhuo" , , "DANIELS, EDWARD S (EDWARD)" , "ZELEZNIAK, ALEX" To: "JOSHI, KAUSTUBH (KAUSTUBH)" 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) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 >> >> >