From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by dpdk.org (Postfix) with SMTP id B72B45953 for ; Tue, 28 Jan 2014 19:15:46 +0100 (CET) Received: from mail-vc0-f179.google.com ([209.85.220.179]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKUuf0INXojFbVzbTD58UNQjTdMOsq4ihy@postini.com; Tue, 28 Jan 2014 10:17:05 PST Received: by mail-vc0-f179.google.com with SMTP id lh14so479380vcb.38 for ; Tue, 28 Jan 2014 10:17:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NJy/fLaIUfML5aKwLeuuJ6pQJ2m6eLh5/LJdSMsN3z8=; b=X6tmS84lhoqsw93tBDF1xR8L0NeWTuOzYZ1nYPBGueRtyWmqED2Dv0dy5cjAnwKcTw aGqWE2OmiyRRR74l10m+c+oglWtUroz58uL1K2Nn0aMqjlivnqpc+vPElKMEe0EWbfnD e6ORShF3OuHwnE9x6rKP7B/4sG2jRS8c7CDxHwiXGDFY+vM/jvAyNztGnSFfNO48PojK qVGwWxIRiCsl/o1Yg5kqY8HJfT4uZEI2P8aJkO/pgsSMyl0wScdO7qhyK9AE6EvIFYdV BiGMDHF0/2K4f5g7NT+9/hBhoUGT7ZW0lrG4XTAvQ13QFevKKuL9GIcR2xRcwrwHDWMv ghJw== X-Gm-Message-State: ALoCoQl6Q1FxGFGBvxRzCUpIj+PeoeNWMaa7ZVzSTspeHK1l+szwqstPNOAFfTQ2Ky5jTQeTwmEw8QZlxnqBKl3fKXEM1BhMnQhkUHF1QrkW6sABeSLWFeMNgA7eloht18kwING04TfF6o6OlIUSIwcEwbyTLsbk+w== X-Received: by 10.58.66.137 with SMTP id f9mr2130818vet.11.1390933024199; Tue, 28 Jan 2014 10:17:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.58.66.137 with SMTP id f9mr2130810vet.11.1390933024121; Tue, 28 Jan 2014 10:17:04 -0800 (PST) Received: by 10.221.32.67 with HTTP; Tue, 28 Jan 2014 10:17:04 -0800 (PST) In-Reply-To: <52E7D13B.9020404@redhat.com> References: <1390873715-26714-1-git-send-email-pshelar@nicira.com> <52E7D13B.9020404@redhat.com> Date: Tue, 28 Jan 2014 10:17:04 -0800 Message-ID: From: Pravin Shelar To: Thomas Graf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dev@openvswitch.org" , dev@dpdk.org, Gerald Rogers , 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: Tue, 28 Jan 2014 18:15:47 -0000 On Tue, Jan 28, 2014 at 7:48 AM, Thomas Graf wrote: > On 01/28/2014 02:48 AM, pshelar@nicira.com wrote: >> >> From: Pravin B Shelar >> >> Following patch adds DPDK netdev-class to userspace datapath. >> Approach taken in this patch differs from Intel=AE DPDK vSwitch >> where DPDK datapath switching is done in saparate process. This >> patch adds support for DPDK type port and uses OVS userspace >> datapath for switching. Therefore all DPDK processing and flow >> miss handling is done in single process. This also avoids code >> duplication by reusing OVS userspace datapath switching and >> therefore it supports all flow matching and actions that >> user-space datapath supports. Refer to INSTALL.DPDK doc for >> further info. >> >> With this patch I got similar performance for netperf TCP_STREAM >> tests compared to kernel datapath. > > > I'm happy to see this happen! > > > >> +static const struct rte_eth_conf port_conf =3D { >> + .rxmode =3D { >> + .mq_mode =3D ETH_MQ_RX_RSS, >> + .split_hdr_size =3D 0, >> + .header_split =3D 0, /* Header Split disabled */ >> + .hw_ip_checksum =3D 0, /* IP checksum offload enabled *= / >> + .hw_vlan_filter =3D 0, /* VLAN filtering disabled */ >> + .jumbo_frame =3D 0, /* Jumbo Frame Support disabled = */ >> + .hw_strip_crc =3D 0, /* CRC stripped by hardware */ >> + }, >> + .rx_adv_conf =3D { >> + .rss_conf =3D { >> + .rss_key =3D NULL, >> + .rss_hf =3D ETH_RSS_IPV4_TCP | ETH_RSS_IPV4 | >> ETH_RSS_IPV6, >> + }, >> + }, >> + .txmode =3D { >> + .mq_mode =3D ETH_MQ_TX_NONE, >> + }, >> +}; > > > I realize this is an RFC patch but I will ask anyway: > > What are the plans on managing runtime dependencies of a DPDK enabled OVS > and DPDK itself? Will a OVS built against DPDK 1.5.2 work with > drivers written for 1.5.3? > > Based on the above use of struct rte_eth_conf it would seem that once > released, rte_eth_conf cannot be extended anymore without breaking > ABI compatibility. The same applies to many of the other user > structures. I see various structures changes between minor releases, > for example dpdk.org ed2c69c3ef7 between 1.5.1 and 1.5.2. > Right, version mismatch will not work. API provided by DPDK are not stable, So OVS has to be built for different releases for now. I do not see how we can fix it from OVS side. DPDK needs to standardize API, Actually OVS also needs more API, like DPDK initialization, mempool destroy, etc.