From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <cunming.liang@intel.com> Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 0D0909AAB for <dev@dpdk.org>; Wed, 25 Feb 2015 09:49:54 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 25 Feb 2015 00:41:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,643,1418112000"; d="scan'208";a="532533566" Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87]) by orsmga003.jf.intel.com with ESMTP; 25 Feb 2015 00:40:45 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 25 Feb 2015 16:49:49 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.62]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.197]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 16:49:47 +0800 From: "Liang, Cunming" <cunming.liang@intel.com> To: Stephen Hemminger <stephen@networkplumber.org> Thread-Topic: ixgbe vector mode not working. Thread-Index: AQHQUJBNLVk7O7HBjk+sxYl37qBGDp0AvJVg//+30YCAAJElkA== Date: Wed, 25 Feb 2015 08:49:48 +0000 Message-ID: <D0158A423229094DA7ABF71CF2FA0DA3118DECD1@shsmsx102.ccr.corp.intel.com> References: <20150224161609.15f590df@urahara> <D0158A423229094DA7ABF71CF2FA0DA3118DE951@shsmsx102.ccr.corp.intel.com> <20150224233651.5e27e791@urahara> In-Reply-To: <20150224233651.5e27e791@urahara> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Nemeth, Balazs" <balazs.nemeth@intel.com>, "dev@dpdk.org" <dev@dpdk.org> Subject: Re: [dpdk-dev] ixgbe vector mode not working. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 25 Feb 2015 08:49:55 -0000 Hi Stephen, Thanks for the info, with rxd=3D4000, I can reproduce it. On that time, it runs out of mbuf. I'll follow up this issue. > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Wednesday, February 25, 2015 3:37 PM > To: Liang, Cunming > Cc: Nemeth, Balazs; Richardson, Bruce; Neil Horman; dev@dpdk.org > Subject: Re: ixgbe vector mode not working. >=20 > On Wed, 25 Feb 2015 04:55:09 +0000 > "Liang, Cunming" <cunming.liang@intel.com> wrote: >=20 > > Hi Stephen, > > > > I tried on the latest mater branch with testpmd. > > 2 rxq and 2 txq as below, vector pmd on both rx and tx. I can't reprodu= ced it. > > I checked your log, on tx side, it looks the tx vector haven't enabled.= (it shows > vpmd on rx, spmd on tx). > > Would you help to share the below params in your app ? > > RX desc=3D128 - RX free threshold=3D32 > > TX desc=3D512 - TX free threshold=3D32 > > TX RS bit threshold=3D32 - TXQ flags=3D0xf01 > > As in your case which using 2 rxq and 1 txq, would you explain the traf= fic flow > between them. > > One thread polling packets from each rxq and send to the specified txq = ? >=20 > Basic thread model of application is same as examples/qos_sched. >=20 > On ixgbe: > RX desc =3D 4000 - RX free threshold=3D32 > TX desc =3D 512 - TX free threshold=3D0 so driver sets default of 32 >=20 > I was setting rx/tx conf but since examples don't went away from that. [LCM] All these params defined in rte_eth_rxconf/rte_eth_txconf which are u= sed during rte_eth_rx/tx_queue_setup. If don't care the value and assign nothing for it, it takes the default val= ue per each device. For ixgbe, the default_txconf will use the vpmd. In your log, it's not. So = that's why I asked for such params. >=20 > The whole RX/TX tuning parameters are a very poor programming model only > a hardware engineer could love. Requiring the application to look at > driver string and choose the magic parameter settings, is in my opnion > an indication of using incorrect abstraction. [LCM] It's not necessary for application to look at such parameter. As you = said, that's only for RX/TX tuning. If tuning, it makes sense to understand what these parameters mean. =20