From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: vhost-switch example: huge memory need and CRC off-loading issue Date: Sat, 8 Aug 2015 09:17:51 +0200 Message-ID: <55C5AD1F.9020902@siemens.com> References: <55C4EB5C.4080001@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: "Ouyang, Changchun" , "dev@dpdk.org" 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) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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