From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id E302CA0096 for ; Wed, 10 Apr 2019 15:10:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A3F4C1B108; Wed, 10 Apr 2019 15:10:43 +0200 (CEST) Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) by dpdk.org (Postfix) with ESMTP id 8E6CE1B108 for ; Wed, 10 Apr 2019 15:10:42 +0200 (CEST) Received: by mail-vk1-f172.google.com with SMTP id x194so545900vke.0 for ; Wed, 10 Apr 2019 06:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4ZA+FStbwlLGFkGeid7km3qH4cluMhxu281g/IU6cCI=; b=dx8gWKHL360kbZ0+hGoglmlXzfuzR+nFreQlVtPgT8AvxeiPxtDlGJb7OpB5FtgQ8w cm4d4MG5t0XCyDdEXWd369Cvj83wdxgy8lnNzd/uczSxFmjDwm+1KUKHXP9pDP0dBR1M 59abt8xdceHfWN8qZz5XyM0mq4PDRlOzoR9hUrL15Nhv8D/PJ6L5bzEW9xFa1gJsfNzt 4DSM+xG5Av1uv2Nsd9Eg6CCS1LG+N+oYRxXzXg1W+5TW7F0Olu5jWvAma8T9xtXcGRJI sukqfPgXa53cAXsySmwoZUlZ9LC62NE0Ifh2IbL+C20f+ygvDw92SPIvc9xbbE4GmHJO TFTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4ZA+FStbwlLGFkGeid7km3qH4cluMhxu281g/IU6cCI=; b=LflYg4AbOlsg/gM1JCNHD78XTdMhx197NIHrnV+JHc+6lgZaeF889m6bC28AA8BNen gxx+wBHs2qt4DO+LHiNupTzBfPJv7XGIhtzBEDwg1ykR1x9Zo/akTAHlHOr5nCFFmPMH vM6IX4sZxuPeluMuAurvLhCnK9OzkaiJXvZKL4ATUgQU9GBtI1zqzRCVfbAZvOBRac4n AUUff4uTRkr+iJp1KD3DkgvunV9AiJwyD7jpdxo7Rn+qhvA7SFdG81SCvTdDnT0tg3ZS KWGNOoIFfccNATlAQwfxMSFoiJLQ6l9qzwTC3VUGOQfjj0VNdGeFYa68oKH8pY8QfMxz X1YA== X-Gm-Message-State: APjAAAVj9qiQF2tUQtVjPx2hTgaqCf5q4Tq9q44xh4hfwjo3mRUk28Qn VTwutOeuIlU8OCTCP8w3CaNWLbHu2BH+KksKwIEPtjzD X-Google-Smtp-Source: APXvYqwojZ4OzN04ux7tqZ//oV7a6sB+sfZGipuQudXw4UAerVDwZvxBwMSvqfVxu4o8YYJJqZzCRko3tqcOL3QyQP4= X-Received: by 2002:a1f:b712:: with SMTP id h18mr23623680vkf.62.1554901841667; Wed, 10 Apr 2019 06:10:41 -0700 (PDT) MIME-Version: 1.0 From: Paras Jha Date: Wed, 10 Apr 2019 09:10:33 -0400 Message-ID: To: dev@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] rte_eth_tx_burst improperly freeing mbufs from KNI mbuf pool X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190410131033.GHPeh6-NwMUR6wIiq0SQ9y6z-PYOo0YO895ym0eR6Co@z> Hi all, I've been chasing down a strange issue related to rte_kni_tx_burst. My application calls rte_kni_rx_burst, which allocates from a discrete mbuf pool using kni_allocate_mbufs. That traffic is immediately sent to rte_eth_tx_burst which does not seem to be freeing mbufs even upon succesful completion. My application follows the standard model of freeing mbufs only if the number of tx mbufs is less than the rx mbufs - however, after sending as many mbufs as there are in the pool, I get KNI: Out of memory soon after when calling rte_kni_rx_burst My concern is that if I free all mbufs allocated by the KNI during rte_kni_rx_burst the application seems to work as intended without memory leaks, even though this goes against how the actual PMDs work. Is this a bug, or intended behavior? The documented examples on the DPDK website seem to only free mbufs if it fails to send, even with the KNI example. B/R