From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bear.techie.net (bear.techie.net [205.134.185.202]) by dpdk.org (Postfix) with ESMTP id 5EDE258EE for ; Sat, 27 Jul 2013 01:26:40 +0200 (CEST) Received: from bear.techie.net (localhost.localdomain [127.0.0.1]) by bear.techie.net (8.13.8/8.13.8) with ESMTP id r6QNQxrw004240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jul 2013 19:26:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=techie.net; s=default; t=1374881219; bh=1GsBbzK7u8SeJkQua5RKGV+Laf5Jo2Cy+bsofWCNEh8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=sMSDsn7dhzNblop4JSoyBLFNhBMosCOSmPIfnZC9zUFrBRcM93nGtholhwoKKykBx DLMm8PshYgLni3ZnehriYDG8jspD0OVIxFFDRUg2fVkHir/kgaPMv/3uFDy5e6Rh2c y46hRp38aFUmgEbz/zY4YlfxVKSVtzgVaV6h2uX4= Received: from localhost (talbert@localhost) by bear.techie.net (8.13.8/8.13.8/Submit) with ESMTP id r6QNQxv8004237; Fri, 26 Jul 2013 19:26:59 -0400 X-Authentication-Warning: bear.techie.net: talbert owned process doing -bs Date: Fri, 26 Jul 2013 19:26:59 -0400 (EDT) From: Scott Talbert X-X-Sender: talbert@bear.techie.net To: jinho hwang In-Reply-To: Message-ID: References: <20130726125322.0ecbca48@nehalam.linuxnetplumber.net> User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dev Subject: Re: [dpdk-dev] NIC Stops Transmitting 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: Fri, 26 Jul 2013 23:26:40 -0000 On Fri, 26 Jul 2013, jinho hwang wrote: >> Thanks for the tips. I don't think I'm running out of mbufs, but I'll check >> that again. I am using these values from one of the examples - which claim >> to be correct for the 82599EB. >> >> /* >> * These default values are optimized for use with the Intel(R) 82599 10 GbE >> * Controller and the DPDK ixgbe PMD. Consider using other values for other >> * network controllers and/or network drivers. >> */ >> #define TX_PTHRESH 36 /**< Default values of TX prefetch threshold reg. */ >> #define TX_HTHRESH 0 /**< Default values of TX host threshold reg. */ >> #define TX_WTHRESH 0 /**< Default values of TX write-back threshold reg. */ >> >> static const struct rte_eth_txconf tx_conf = { >> .tx_thresh = { >> .pthresh = TX_PTHRESH, >> .hthresh = TX_HTHRESH, >> .wthresh = TX_WTHRESH, >> }, >> .tx_free_thresh = 0, /* Use PMD default values */ >> .tx_rs_thresh = 0, /* Use PMD default values */ >> }; >> >> /* >> * Configurable number of RX/TX ring descriptors >> */ >> #define RTE_TEST_TX_DESC_DEFAULT 512 >> static uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT; >> > I am wondering whether you use multiple cores accessing the same > receive queue. I had this problem before, but after I make the same > number of receiving queues as the number of receiving cores, the > problem disappeared. I did not dig more since I did not care how many > receive queues I have did not matter. Jinho, Thanks. I have only one queue (should I be using more?) but as far as I know, I'm only using one core to transmit as well. Scott