From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 00FE81E2F for ; Tue, 10 Jan 2017 14:29:59 +0100 (CET) Received: by mail-wm0-f45.google.com with SMTP id c85so127941627wmi.1 for ; Tue, 10 Jan 2017 05:29:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:cc:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=tPUajZ3kMFO9I1nszktZLq5jf50d8LkENZ5l3jTp+Tk=; b=Xm1ZTe5u9rwthteXLZnKvmnUq7+ZuNGzq3hBdbH3ZYsnklK1f053SagcHsymm+/xVK Fl+wgH6eFyfsGlK8N6UM/zfWRyxVr9HdtTNov063W3jbvSCRJgcZkC4G1ywqGGKZ5GI2 A2ai+VZ05pUx0jP2rxovsaoLax2wniuGm5u3fISN67469sxP++EZQ5VylckxhgK7j11s dMHiGo9GF8xVz4m2Ln5fe6BFzBnxHPtDea4csRyNBmksw1hSFiKjcx/qXMAq99aPvk5S QYnAfeso0e+FDAclLh9XkraMpQwtCmGzkb7Trb0G8Htca6boqHQbE6IJhMzJQ7jB3bAM F0cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=tPUajZ3kMFO9I1nszktZLq5jf50d8LkENZ5l3jTp+Tk=; b=gn7ZSDKJPBFL/oiKE2RvCPdGXBONu95FwA0jRHAK6JGyXZaA7ogUMDksbA3BSsyMR7 xMrRca7QdpWS/99QgZM1m34BTkSOe4ZwSaCgz5qGpgOyr3Jts7zLgwQPK92KeYDtoomh H7UYPb3j9y7zhg3KpExVq9dMAy9fJUFmcGc1Unknqnz51KBkzL2iX3HRSSMVOyqFZ3uu 4EmljIoygTg71PVNHlAl7vbYwXccvSMPFT3cyO1qkrGaz3YRWnpITnOs21co3rsncUdW g0pVcS144jEpkYcGjGkwm1woXNe2cy1qrwhFig/qNAHoR6ha8T8pLB3+1sDTst4tp6Z5 Chyg== X-Gm-Message-State: AIkVDXJgMPEBLE0Ff4PVfFSebGQCXuDuW2QIcNE724XdvvCmiMCkL5TRxFu+N5ZUSAy2bSgT X-Received: by 10.223.166.167 with SMTP id t36mr1980982wrc.18.1484054999426; Tue, 10 Jan 2017 05:29:59 -0800 (PST) Received: from [10.16.0.240] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id d85sm24623302wmd.17.2017.01.10.05.29.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 05:29:58 -0800 (PST) From: Vincent JARDIN To: Scott Daniels , dev@dpdk.org References: <4341B239C0EFF9468EE453F9E9F4604D3C5CA3DA@shsmsx102.ccr.corp.intel.com> <586D647A.5040607@research.att.com> Cc: kaustubh@research.att.com, az5157@att.com, "Chen, Jing D" Organization: www.6wind.com Message-ID: Date: Tue, 10 Jan 2017 14:29:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <586D647A.5040607@research.att.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF 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: Tue, 10 Jan 2017 13:30:00 -0000 Hi Scott, Le 04/01/2017 à 22:09, Scott Daniels a écrit : > With holidays we are a bit late with our thoughts, but would like to > toss them into the mix. Same, I hope I am not missing emails. I do appreciate your arguments, it provides lot of light. See below, > The original NAK is understandable, however having the ability to > configure the PF via DPDK is advantageous for several reasons: > > 1) While some functions may be duplicated and/or available from the kernel > driver, it is often not possible to introduce new kernel drivers into > production without a large amount of additional testing of the entire > platform which can cause a significant delay when introducing a DPDK based > product. If the PF control is a part of the DPDK environment, then only > the application needs to pass the operational testing before deployment; a > much more simple task. So we agree: you confirm that your foresee the benefits of using DPDK to *bypass the role of the Kernel being the PF* of reference for the hypervisor. > 2) If the driver changes are upstreamed into the kernel proper, the > difficulty of operational readiness testing increases as a new kernel is > introduced, and further undermines the ability to quickly and easily > release a DPDK based application into production. While the application > may eventually fall back on driver and/or kernel support, this could be > years away. I do agree with the benefits of the agilities and the upsides it brings. But they are other options to get the same agility without creating a fragmentation of PFs. For example, you do not have to update the whole kernel, you can just update the PF kernel module that can be upgraded with the latest needed features. > 3) As DPDK is being used to configure the NIC, it just seems to make > sense, for consistency, that the configuration capabilities should include > the ability to configure the PF as is proposed. From this perspective, the kernel modules are fine for the PF: most kernels of hypervisors support it without the need to upgrade their kernels. To summarize, I understand that you need a flexible way to upgrade PF features without touching/changing the kernel. So let's check the kernel module option? VFD brings some interesting capabilities, could it be a way to push and stimulate the i40e features instead of using DPDK? https://sourceforge.net/projects/e1000/files/i40e%20stable/ for instance could be better stimulated. Best regards, Vincent