From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by dpdk.org (Postfix) with ESMTP id CB80A5907 for ; Thu, 13 Mar 2014 08:36:28 +0100 (CET) Received: by mail-lb0-f180.google.com with SMTP id 10so394108lbg.39 for ; Thu, 13 Mar 2014 00:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7G3urdpRYWPyy1uFN3z6eGgHbabFEgjYqx9wg2teM84=; b=dtsWZFiegZkz+fZxByjSn2qGK7S3EofHrsfg8wKjhr6LtEnj25o1tiYaaTcCsE/PVO fh0DjwWaSNcblfJ5P3/ufd5XXnjRLfsvvslE7pQizKc5ziRwGjfHcOjqABRWMG0Cwur5 QHXh7fJwq3HnhW9c4rVrv/edXp2oS0LIKtpYOxf1k60DZUJw98Z8h1bWa5MEYpWseMS7 cRNdoT3A8lmembvgjVmfekADM+ybPMyh1v7yjlbr+QWucz4vJyAUrD5scmMPs22SYGJn vwHFtRQ9tfCcGNx6a4WO2ipnYjYMPLob4pPMsFsdwD8RSNtG8S3ILGS9lW4TvwynYcmz ggeA== X-Received: by 10.112.46.225 with SMTP id y1mr206907lbm.12.1394696278423; Thu, 13 Mar 2014 00:37:58 -0700 (PDT) Received: from [172.16.141.133] (sestofw01.enea.se. [192.36.1.252]) by mx.google.com with ESMTPSA id th3sm1416118lbb.11.2014.03.13.00.37.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 00:37:54 -0700 (PDT) Message-ID: <5321604E.50808@gmail.com> Date: Thu, 13 Mar 2014 08:37:50 +0100 From: =?UTF-8?B?RGF2aWQgTnlzdHLDtm0=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?UTF-8?B?RnJhbsOnb2lzLUZyw6lkw6lyaWMgT3pvZw==?= , 'Thomas Graf' , 'Vincent JARDIN' References: <1390873715-26714-1-git-send-email-pshelar@nicira.com> <52E7D13B.9020404@redhat.com> <52E8B88A.1070104@redhat.com> <52E8D772.9070302@6wind.com> <52E8E2AB.1080600@redhat.com> <52E92DA6.9070704@6wind.com> <52E936D9.4010207@redhat.com> <00ef01cf1d33$5e509270$1af1b750$@com> In-Reply-To: <00ef01cf1d33$5e509270$1af1b750$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: dev@openvswitch.org, dev@dpdk.org, dpdk-ovs@ml01.01.org Subject: Re: [dpdk-dev] [ovs-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based 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: Thu, 13 Mar 2014 07:36:29 -0000 On 2014-01-29 21:47, François-Frédéric Ozog wrote: >>> First and easy answer: it is open source, so anyone can recompile. So, >>> what's the issue? >> >> I'm talking from a pure distribution perspective here: Requiring to >> recompile all DPDK based applications to distribute a bugfix or to add >> support for a new PMD is not ideal. > >> >> So ideally OVS would have the possibility to link against the shared >> library long term. > > I agree that distribution of DPDK apps is not covered properly at present. > Identifying the proper scheme requires a specific analysis based on the > constraints of the Telecom/Cloud/Networking markets. > > In the telecom world, if you fix the underlying framework of an app, you > will still have to validate the solution, ie app/framework. In addition, the > idea of shared libraries introduces the implied requirement to validate apps > against diverse versions of DPDK shared libraries. This translates into > development and support costs. > > I also expect many DPDK applications to tackle core networking features, > with sub micro second packet handling delays and even lower than 200ns > (NAT64...). The lazy binding based on ELF PLT represent quite a cost, not > mentioning that optimization stops are shared libraries boundaries (gcc > whole program optimization can be very effective...). Microsoft DLL linkage > are an order of magnitude faster. If Linux was to provide that, I would > probably revise my judgment. (I haven't checked Linux dynamic linking > implementation for some time so my understanding of Linux dynamic linking > may be outdated). > > >> >>> I get lost: do you mean ABI + API toward the PMDs or towards the >>> applications using the librte ? >> >> Towards the PMDs is more straight forward at first so it seems logical to >> focus on that first. > > I don't think it is so straight forward. Many recent cards such as Chelsio > and Myricom have a very different "packet memory layout" that does not fit > so easily into actual DPDK architecture. > > 1) "traditional" architecture: the driver reserves X buffers and provide the > card with descriptors of those buffers. Each packet is DMA'ed into exactly > one buffer. Typically you have 2K buffers, a 64 byte packet consumes exactly > one buffer > > 2) "alternative" new architecture: the driver reserves a memory zone, say > 4MB, without any structure, and provide a a single zone description and a > ring buffer to the card. (there no individual buffer descriptors any more). > The card fills the memory zone with packets, one next to the other and > specifies where the packets are by updating the supplied ring. Out of the > many issues fitting this scheme into DPDK, you cannot free a single mbuf: > you have to maintain a ref count to the memory zone so that, when all mbufs > have been "released", the memory zone can be freed. > That's quite a stretch from actual paradigm. > > Apart from this aspect, managing RSS is two tied to Intel's flow director > concepts and cannot accommodate directly smarter or dumber RSS mechanisms. > > That said, I fully agree PMD API should be revisited. Hi, Sorry for jumping in late. Perhaps you are already aware of OpenDataPlane, which can use DPDK as its south bound NIC interface. > > Cordially, > > François-Frédéric >