From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.161.194]) by dpdk.org (Postfix) with ESMTP id 7C26F9A91 for ; Mon, 16 May 2016 17:31:07 +0200 (CEST) Received: by mail-yw0-f194.google.com with SMTP id u62so19907860ywe.3 for ; Mon, 16 May 2016 08:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=f2R/iFg75BJdgLGxxTKID1sC4TxDNDYDNANTpmBk4x8=; b=DBAGy0XDy6ytA/f4yNo/3FwMUv1WyYkmHbeXGzIFajMX0s2lub6T2b82A6CNyfyBSH S6rpobTLzf4eG4H6KNYQzvAhVSdyoj15xpLKMNG8DUDyilP2FpgjFlknA52BSOmu4ljr IE7tfTPg/L9N4kH96fURPjwPmCsI7tGz/TjVVQmPp8SeSbO2Nae36S4enHHhUEpRQkJu s9uiCAN3g4tMGBVgiA/xFeEs1pv4WGCtSzeGLv8aQsCjNaB6g+PS9NJUOWbtfvwsHsSb 0eTV0jfD1FHGP6M/Gt6m7wtGjQwGNfWYa8oM7l6M+AACjMYRRtsEyARz7DuJdJ8uQaj0 HPzg== 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; bh=f2R/iFg75BJdgLGxxTKID1sC4TxDNDYDNANTpmBk4x8=; b=awcZU5z/bm5HmHt/hJ7hktUQWPEa0ufVNm7K8sCzKmEJB8XWylG2gizzaY5TdMcm6f Cx6wFeIxs5ex10YxOf/Wus/VxQagdIZe/TPo5mnTMSVspe1f7CKvLhHlzsnHhnD6jM5b qOp2PL1PDZLcgmexOxcjx6xXc4XMq9eMgroSe0Rk6nxMJZ5N7JgBicRkKaUZNPnHKuoO TIXTSFIPvhTY/K5HKtts/uSsMth+9hTTRGEcEvWVbL9fPUZnN1FwTR15qmrjAs+iZveg A15xFsUgYvnKQjSHOTt+7vQ1BGdcS+1G+uUeuTCtkLIDL9ZmmnQhC5GaLkpoK/rONDpQ 5dlg== X-Gm-Message-State: AOPr4FWjlOMTKZJc+Dkx74eCXzATp2+vT2inypipuHSBtg+wTkw94/Hg7E14jB1ij52c+Zd7W8RFps1gZN4X6w== MIME-Version: 1.0 X-Received: by 10.37.11.22 with SMTP id 22mr882954ybl.184.1463412666830; Mon, 16 May 2016 08:31:06 -0700 (PDT) Received: by 10.129.70.11 with HTTP; Mon, 16 May 2016 08:31:06 -0700 (PDT) In-Reply-To: <5739ACFF.4000506@intel.com> References: <5739ACFF.4000506@intel.com> Date: Mon, 16 May 2016 08:31:06 -0700 Message-ID: From: ALeX Wang To: Ferruh Yigit Cc: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] possible kni bug and proposed fix 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: Mon, 16 May 2016 15:31:07 -0000 Hi Ferruh, Thx for pointing out the 'fill alloc_q with these mubfs _until it gets full_.', I saw the size of all queues are 'KNI_FIFO_COUNT_MAX (1024)'... The corresponding memory required is more than what I specify as 'socket_mem' (since i'm using VM)... Also, in my use case, I only `tcpreplay` through the kni interface, and my application only do rx and then free the 'mbufs'. So there is no tx at all. So, in my case, I still think this is a bug/defect, or somewhere i still misunderstand, P.S. The description here seems to be inverted, http://dpdk.org/doc/api/rte__kni_8h.html#a0cdd727cdc227d005fef22c0189f3dfe 'rte_kni_rx_burst' does the 'It handles allocating the mbufs for KNI interface alloc queue.' Thanks, Alex Wang, On 16 May 2016 at 04:20, Ferruh Yigit wrote: > On 5/15/2016 5:48 AM, ALeX Wang wrote: > > Hi, > > > > When using the kni module to test my application inside > > debian (virtualbox) VM (kernel version 4.4), I get the > > > > "KNI: Out of memory" > > > > from syslog every time I `tcpreply` packets through > > the kni interface. > > > > After checking source code, I saw that when I call > > 'rte_kni_rx_burst()', no matter how many packets > > are actually retrieved, we always call 'kni_allocate_mbufs()' > > and try allocate 'MAX_MBUF_BURST_NUM' more > > mbufs... I fix the issue via using this patch below, > > > > Could you confirm if this is an actual bug? > > > > Hi Alex, > > I don't think this is a bug. > > kni_allocate_mbufs() will allocate MAX_MBUF_BURST_NUM mbufs as you > mentioned. And will fill alloc_q with these mubfs _until it gets full_. > And if the alloc_q is full and there are remaining mbufs, they will be > freed. So for some cases this isn't the most optimized way, but there is > no defect. > > Since you are getting "KNI: Out of memory", somewhere else can be > missing freeing mbufs. > > mbufs freeing done in rte_kni_tx_burst(), I can guess two cases that can > cause problem: > a) not calling rte_kni_tx_burst() frequent, so that all free mbufs > consumed. > b) calling rte_kni_tx_burst() with number of mbufs bigger than > MAX_MBUF_BURST_NUM, because this function frees at most > MAX_MBUF_BURST_NUM of mbufs, but if you are calling calling > rte_kni_tx_burst() with bigger numbers, this will cause mbufs to stuck > in free_q > > > Regards, > ferruh > > > -- Alex Wang, Open vSwitch developer