From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f195.google.com (mail-pf0-f195.google.com [209.85.192.195]) by dpdk.org (Postfix) with ESMTP id 16005BD28 for ; Sat, 14 Jan 2017 00:10:41 +0100 (CET) Received: by mail-pf0-f195.google.com with SMTP id f144so10128366pfa.2 for ; Fri, 13 Jan 2017 15:10:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=S8QaUzrAH5yhQLWi8z+VrRnFKlaBt18dOkVUvqT46M4=; b=cksTLReeEo6GsCxpfkweXICTOSrjtdjd0NANJVUe/ghym7oZk7rTKqyWUGy1mNsWtu ZVK1CK9w/oTrYT+83Bg5AjFqra2sqJhiSJlws23HXugmxvLJBo/RNll9kdVNMOSmRiMG edpBkHcmk/do9u4UesAik4C38MNbPeYalFkztwnG5LhI5ll87N2t4VtM29RFSUE8UCHd 9xEWtHvJlr/kP597Z3Edawt2xCqC7fmmgSXRSkQcuS5EUhpaPe5li6RtGWLITFLDKRF8 Snt+X/Cs4pckNcrXnNXLxnrH6JoN4zQDsvanZJo0LlWVp0xlCZjt7BSPH97LpKGjd0kq w2cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=S8QaUzrAH5yhQLWi8z+VrRnFKlaBt18dOkVUvqT46M4=; b=eP6NHlHskyUSlviuPVEvk1BcVFhRII7Gzx9qGsaeULRxYrFULFaWFoTgBJmcGaBvlu uxCIil0jEFlNVd0lPhiAUz3ocNgloTdOiCXxO3XV6RUJuG5hr/2UB8wFZxI2IMnOl/Y5 l1MjfcGzy0rDdbhSX8wSr6rOtmZbjISVVbSt9+onLl+OGuKhP7BgVaLXNgTcJ2LDoOJc AIhS7rWpb8tlnjoz7V2zHqlxZsaYRD0W8XCmZM0KZKiETeN0NFhUMZ7HIxiBvLz07K5N RVqUestrdOPQQbYBzpT+XMKTyqK1SxyrxmxgW4a6B59yEotjFiFhSxILhIto15XJkcL5 wkhw== X-Gm-Message-State: AIkVDXJaGySPWw74C61MtqoMcMkHmmymCbE4ADkgy02qUnZAmAvNIXHFkAI0a9RqiGLJTg== X-Received: by 10.84.167.168 with SMTP id d37mr33010065plb.71.1484349041243; Fri, 13 Jan 2017 15:10:41 -0800 (PST) Received: from [192.168.1.3] ([72.168.145.15]) by smtp.googlemail.com with ESMTPSA id q5sm31699882pgf.45.2017.01.13.15.10.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 15:10:40 -0800 (PST) To: "JOSHI, KAUSTUBH (KAUSTUBH)" , Vincent Jardin 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> <1598d329eb0.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> <194F5517-88BD-4BDB-B0FC-A6AC6B08F588@research.att.com> Cc: "Zhang, Helin" , "Lu, Wenzhuo" , "dev@dpdk.org" , "DANIELS, EDWARD S (EDWARD)" , "ZELEZNIAK, ALEX" From: John Fastabend Message-ID: <58795E60.8060609@gmail.com> Date: Fri, 13 Jan 2017 15:10:24 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <194F5517-88BD-4BDB-B0FC-A6AC6B08F588@research.att.com> Content-Type: text/plain; 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: Fri, 13 Jan 2017 23:10:42 -0000 On 17-01-11 06:51 AM, JOSHI, KAUSTUBH (KAUSTUBH) wrote: > Also, the kernel drivers have no concept of passing VF messages to upstream "decision making” (or policy enforcement) software like VFd. > > On Jan 11, 2017, at 9:49 AM, Kaustubh Joshi > wrote: > > When Alex from our team started working on Niantic last year, the following were the list of gaps in the kernel drivers we had a need to fill: > Thanks for the list its nice to see concrete examples. I can provide latest upstream status for what its worth. > Direct traffic to VF based on more than one outer VLAN tags Kernel supports this but ixgbe/i40e drivers need to pull in code to enable it. > Optionally strip on ingress (to PF) and insert on egress VLAN tag This is just a PVID per VF right? This should be working now on ixgbe I would have to check though. > Disable/enable MAC and VLAN anti spoofing separately Needs kernel patch. > Mirror traffic from one VF to the other Kernel supports this but driver is missing feature. > Enable/Disable local switching per VF Local switching? I'm guessing this means you want all traffic to go to network regardless of MAC/etc. A sort of per port VEPA mode? > Collect statistics per VF pkts/octets in/out Under development. > Enable/disable Mcast/unknown unicast per VF Under development. > Manage up to 8 TC per VF with one strict priority queue > Manage per VF per TC bandwidth allocations Needs kernel patch. > Manage LACP status visibility to the VFs (for NIC teaming using SRIOV) I've not even thought to do this yet so its a good catch. > > Most of these are VF management functions, and there is no standardized way to do VF management in the kernel drivers. Besides, most of the use-cases around SRIOV need DPDK in the VF anyway (so the target communities are aligned) and the PF DPDK driver for ixgbe already existed, so it made sense to add them there - no forking of the PF driver was involved and there is no additional duplicate code. > So I wont argue against we already have DPDK and VFs are DPDK and updating is a problem per other email. But I think we can at least get kernel support for the above. Thanks, John > Cheers > > KJ > > > On Jan 11, 2017, at 6:03 AM, Vincent Jardin > wrote: > > 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 > > > > > > >