From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by dpdk.org (Postfix) with ESMTP id 113352E41 for ; Sat, 8 Aug 2015 09:17:52 +0200 (CEST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.15.1/8.15.1) with ESMTPS id t787HqDm019378 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 8 Aug 2015 09:17:52 +0200 Received: from md1f2u6c.ww002.siemens.net ([139.22.125.95]) by mail2.siemens.de (8.15.1/8.15.1) with SMTP id t787Hprq028530; Sat, 8 Aug 2015 09:17:51 +0200 To: "Ouyang, Changchun" , "dev@dpdk.org" References: <55C4EB5C.4080001@siemens.com> From: Jan Kiszka Message-ID: <55C5AD1F.9020902@siemens.com> Date: Sat, 8 Aug 2015 09:17:51 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] vhost-switch example: huge memory need and CRC off-loading issue 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: Sat, 08 Aug 2015 07:17:53 -0000 On 2015-08-08 02:39, Ouyang, Changchun wrote: > > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jan Kiszka >> Sent: Saturday, August 8, 2015 1:31 AM >> To: dev@dpdk.org >> Subject: [dpdk-dev] vhost-switch example: huge memory need and CRC off- >> loading issue >> >> Hi again, >> >> two findings in the vhost-switch example code that can cause grey hair for >> starters: >> >> - MAX_QUEUES of 512 causes pretty high memory need for the application >> (something between 1 and 2G) - is that really needed? I'm now running >> with 32, and I'm able to get away with 256M. Can we tune this >> default? > > Don't think we need change default just because your platform is 32, > Well, my platform is 128, other platform may have other value, :-) Then let's make it configurable or explore the actual device needs before allocating the buffer. The impact on memory consumption is way too big to hard-code this, specifically as this is per physical port IIUC. > >> >> - hw_strip_crc is set to 0, but either the igb driver or the ET2 quad >> port adapter I'm using is ignoring this. It does strip the CRC, so > > Igb and ET2 should NOT ignore it. Well, they do not listen to us. What can I do to debug this? According to eth_igb_rx_init, hw_strip_crc affects E1000_RCTL_SECRC in the receiver control registers, and debugging confirms this (the bit is unset in all E1000_RCTL accesses). But there is still no CRC at the end of received packets. Possibly, there is some other knob that controls CRC stripping? Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux