From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by dpdk.org (Postfix) with ESMTP id A60358E63 for ; Tue, 19 Jan 2016 02:36:30 +0100 (CET) Received: by mail-pa0-f45.google.com with SMTP id cy9so442379481pac.0 for ; Mon, 18 Jan 2016 17:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=s54C7+SyoRHepYGVrA0LDsYo8wxkUoNdZyd8/Kr1k40=; b=iYfvo5BSJ8b8G9HxLCwUVFcFX22BoYC4iXWGMLkmSmwir33HfFqBB61LHsOZf0srjW vxIVf21PenV76d0TnmcQ9T6hPyVWGVbEZIsl65997ykKxOAiX4ZvzBfUqd0Rx1wLSeqi twJKpWpIMHukEOLQo5tewYyxv7ROF9H/v6at1ki4rib0Q4rTXbJYqWR3FaODXyzWE7tl t1Kpv2RNOGk3QyMp1ICwFpdM25eDlb6q7qSRmv7kMGSJvzBAPXXOVHYk6UXJSGTKzXWd V0WlWM0CBbu7ywYZw00QP6+Ipm1A3TwQ4/f1d1MfksAgcfkZHTbD3xQ2P2pMG5Q8mrB7 +Msg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=s54C7+SyoRHepYGVrA0LDsYo8wxkUoNdZyd8/Kr1k40=; b=OBJe055vSjwmyKybqUYsoO3yK7dxmQF/X//cMEQOJU/fEoWSaZpF28xlaraPm1qmc7 kvpDt/p0HdBckXqbNgr4GWDTgJJKhexpTOyEF/bBmVQpgEF6+/ObQP4bkemADaKtrQIL QctWTscAXySm6KcdX4tE+1E3v6c4MyVx2oCnMncv3fy4GTNrOmdBna1tB2K7n/2t+3LK UHzKtJjhpeN//Ir5BVycUNEkdafSb3Lm6+eLIwman0ZQtyvZOL0GuWyYcZitPrwz+Svp wcvz5L7yWo0cqiPa1ppaTx+hyr9vYk4KJYgDa6+rgpCvESyqZoEM1p7FffnlNLgIHovD izww== X-Gm-Message-State: ALoCoQkxpOwvoKThx6weQGsCeMa0LO+8U8I8CQY3ucAPSEDvK3HmBkPiPUTcAopYqmZEwjVjDnRAphYWX4UD2BPM1HvxxEVfXQ== X-Received: by 10.66.90.133 with SMTP id bw5mr40527222pab.22.1453167389974; Mon, 18 Jan 2016 17:36:29 -0800 (PST) Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id r89sm36777045pfa.57.2016.01.18.17.36.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jan 2016 17:36:29 -0800 (PST) Date: Mon, 18 Jan 2016 17:36:37 -0800 From: Stephen Hemminger To: Jay Rolette Message-ID: <20160118173637.09afa765@xeon-e3> In-Reply-To: References: <1452874684-12750-1-git-send-email-ferruh.yigit@intel.com> <20160118151230.194a95c6@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: DPDK Subject: Re: [dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 01:36:31 -0000 On Mon, 18 Jan 2016 17:48:51 -0600 Jay Rolette wrote: > On Mon, Jan 18, 2016 at 5:12 PM, Stephen Hemminger < > stephen@networkplumber.org> wrote: > > > On Fri, 15 Jan 2016 16:18:01 +0000 > > Ferruh Yigit wrote: > > > > > This work is to make DPDK ports more visible and to enable using common > > > Linux tools to configure DPDK ports. > > > > > > Patch is based on KNI but contains only control functionality of it, > > > also this patch does not include any Linux kernel network driver as > > > part of it. > > > > I actually would like KNI to die and be replaced by something generic. > > Right now with KNI it is driver and hardware specific. It is almost as if > > there > > are three drivers for ixgbe, the Linux driver, the DPDK driver, and the > > KNI driver. > > > > Any ideas about what that would look like? Having the ability to send > traffic to/from DPDK-owned ports from control plane applications that live > outside of (and are ignorant of) DPDK is a platform requirement for our > product. > > I'm assuming that isn't uncommon, but that could just be the nature of the > types of products I've built over the years. > > That said, I'd love there to be something that performs better and plays > nicer with the system than KNI. Maybe something using switchdev API in kernel? Or making the bifurcated driver model work? Or something more like netmap where actual driver code is in kernel for controlling hardware and only ring buffers need to be exposed. The existing DPDK although high performance suffers from lots of cases of DRY (https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). For a recent example, we discovered that VLAN's don't work on I350 because the code to handle the workaround for byte swapping is not there in DPDK (it is in the Linux driver). Because DPDK causes there to be has two driver code bases, this kind of problem is bound to occur. I realize this is a very hard problem, and there is no quick solution. Any long term solution will require work in both spaces kernel and DPDK.