From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com [209.85.213.43]) by dpdk.org (Postfix) with ESMTP id 574C25585 for ; Thu, 15 Dec 2016 13:55:49 +0100 (CET) Received: by mail-vk0-f43.google.com with SMTP id x186so70180703vkd.1 for ; Thu, 15 Dec 2016 04:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinite-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=72q4iyGpdqD8AVAjMu6pq96D2stJpWrFM9V4pImend8=; b=LRvUy95HamWCrAggaE5n0JcQTBi6C6ctFHYU2lhMQicb0lSNY5j1gCaKsW3t7Mfwvz wRTqUQkiv+LoERoDrgF1sCITfXIeTv1GIU5Oqieyo+yojcSO8BZ2qXWbaV39gd7wFtEA Itxg5pOhsbXuHc3YAUV5mYBNmD2LM8TaX7miaA1YTXDoPfDySeCX7qgBtECtV+nUYbeO zrLVEKqE4VLp/nymfxV7MZZzpgIfKrgs1N2qduSDk3Qp2USkaa7DwZv/lr0oh9nFjZtY LxY7RbkEuDzhNTBYAQI7FMt7olniOujPXZXwSC39d4FkcmIo0LJys+NLdOygQrixVkYT 3oFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=72q4iyGpdqD8AVAjMu6pq96D2stJpWrFM9V4pImend8=; b=RxIhmHE/AfXBGHP5EckcGpVYUJ1r1v0vVYXHGyPaPLJPcwy3R4dwohaVEz1xEgnBek kuBiRKZL2wwWXzQz4vhgTvDZKdVK0HEjN7XpF0oK/c6qmxrpOM7D037NXKTBxhe/1tXi FqjSSJkyNv+7JJZK87gDfBgGqGGggxRNX3VD3C7KRxTUbRKNrfsxrXX+3Hv2O1qmh+NN lbrFdAWk004kPnB5AceUGh+lrS/F81i3vi28TJtON1EYchv0VQ1B7lW/YRTA0e4M4r+O 4YvpA0qj2Fl5zi1sQuCwBi0I81J3D09mU/yrvlY3Ka1bUMivL2IIb31OvPvXnavkalxg uNPw== X-Gm-Message-State: AKaTC01V8q7ZTHp02Oj+11UERxlwmJ/6akBs0S8PMiV7tfZ5tjHcF4yrSMW/Om1dMQKFwawVF4E3mbOsrCHvfw== X-Received: by 10.31.96.71 with SMTP id u68mr462130vkb.72.1481806548579; Thu, 15 Dec 2016 04:55:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.82.15 with HTTP; Thu, 15 Dec 2016 04:55:48 -0800 (PST) In-Reply-To: References: <20161214154049.698de2e8@xeon-e3> From: Jay Rolette Date: Thu, 15 Dec 2016 06:55:48 -0600 Message-ID: To: "Mcnamara, John" Cc: Stephen Hemminger , "dev@dpdk.org" , "Yigit, Ferruh" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] KNI broken again with 4.9 kernel 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: Thu, 15 Dec 2016 12:55:49 -0000 On Thu, Dec 15, 2016 at 6:01 AM, Mcnamara, John wrote: > > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger > > Sent: Wednesday, December 14, 2016 11:41 PM > > To: dev@dpdk.org > > Subject: [dpdk-dev] KNI broken again with 4.9 kernel > > > > /build/lib/librte_eal/linuxapp/kni/igb_main.c:2317:21: error: > > initialization from incompatible pointer type [-Werror=incompatible- > > pointer-types] > > .ndo_set_vf_vlan = igb_ndo_set_vf_vlan, > > ^~~~~~~~~~~~~~~~~~~ > > > > I am sure Ferruh Yigit will fix it. > > > > Which raises a couple of questions: > > 1. Why is DPDK still keeping KNI support for Intel specific ethtool > > functionality. > > This always breaks, is code bloat, and means a 3rd copy of base code > > (Linux, DPDK PMD, + KNI) > > > > 2. Why is KNI not upstream? > > If not acceptable due to security or supportablity then why does it > > still exist? > > > > 3. If not upstream, then maintainer should track upstream kernel changes > > and fix DPDK before > > kernel is released. The ABI is normally set early in the rc cycle > > weeks before release. > > > Hi Stephen, > > On point 2: The feedback we have always received is that the KNI code > isn't upstreamable. Do you think there is an upstream path? > > > If not acceptable due to security or supportablity then why does it > > still exist? > > The most commonly expressed reason when we have asked this question in the > past (and we did again at Userspace a few months ago) is that the people > who use it want the performance. > We use KNI in our product. In our case, it's because it allows "normal" non-DPDK apps in the control plane to interact with traffic on the fastpath as needed. Having everything under the sun live in DPDK's essentially flat memory space is not great for security or stability. It helps time to market by being able to use existing programs that interface to the network via sockets instead of having to limit ourselves to the relatively tiny set of libraries out there that work directly DPDK. Double bonus on the time-to-market argument since we can implement functionality in other higher-level languages as appropriate. Performance-wise, KNI is "ok" but not great. It's not clear to me why it is so much slower than using a NIC normally (not via DPDK) via the Linux network stack. Copying data between sk_buf and mbuf is never going to be cheap, but comparing that to what happens through all the kernel network stack layers, the end result seems too slow. That said, it's still faster than TAP/TUN interfaces and similar approaches. Jay On point 3: We do have an internal continuous integration system that runs > nightly compiles of DPDK against the latest kernel and flags any issues. > > John >