Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758133AbbLBM3S (ORCPT ); Wed, 2 Dec 2015 07:29:18 -0500 Received: from mailout1.w1.samsung.com ([210.118.77.11]:32166 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755148AbbLBM3P convert rfc822-to-8bit (ORCPT ); Wed, 2 Dec 2015 07:29:15 -0500 X-AuditID: cbfec7f5-f79b16d000005389-ed-565ee4182c5e From: Pavel Fedin To: "'Sunil Kovvuri'" , "'Eric Dumazet'" Cc: "'Linux Netdev List'" , "'LKML'" , "'LAKML'" , "'Sunil Goutham'" , "'Sunil Goutham'" References: <1448961223-41888-4-git-send-email-sunil.kovvuri@gmail.com> <01d101d12c46$2de43b40$89acb1c0$@samsung.com> <1448983985.25582.35.camel@edumazet-glaptop2.roam.corp.google.com> <00cb01d12ce0$9f090540$dd1b0fc0$@samsung.com> <00eb01d12cec$a32aa500$e97fef00$@samsung.com> In-reply-to: <00eb01d12cec$a32aa500$e97fef00$@samsung.com> Subject: RE: [PATCH 3/6] net: thunderx: Increase transmit queue length Date: Wed, 02 Dec 2015 15:29:10 +0300 Message-id: <013301d12cfd$0c958a90$25c09fb0$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-Mailer: Microsoft Outlook 14.0 Thread-index: AQGScnHROc58U50eD5J6ppH35rF/UQG2SVlqAT5pB6wB6Z4d1QJ5t4arAWZheWEA/VqCD57nNkTQ Content-language: ru X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsVy+t/xK7oST+LCDA7t5LTY9/4sm8Wmx9dY LS7vmsNmcWyBmMXlyz+YLQ583MtisajpHYsDu8eM34tYPDac6Gf12DnrLrvH5iX1Hp83yQWw RnHZpKTmZJalFunbJXBlvNrfylzwg7viRUtIA+M6zi5GDg4JAROJVwfyuhg5gUwxiQv31rN1 MXJxCAksZZTYvPgeK4TznVHi4qWTTCBVbALqEqe/fmABsUUEIiSeH/jKDmIzC7xilLjWIQnR 8JVJYs3C62ANnAJWEtt2TWIFsYUF3CTmbF3NBmKzCKhK7Dj9GszmFbCUODjtBJQtKPFj8j0W iKHqEpPmLWKGsLUlnry7wApxqoLEjrOvGSGOiJFYuOgrVL2IxLR/95gnMArNQjJqFpJRs5CM moWkZQEjyypG0dTS5ILipPRcI73ixNzi0rx0veT83E2MkEj5uoNx6TGrQ4wCHIxKPLwreOLC hFgTy4orcw8xSnAwK4nweskAhXhTEiurUovy44tKc1KLDzFKc7AoifPO3PU+REggPbEkNTs1 tSC1CCbLxMEp1cAYLHx/yTTmnDD+bc67G2ac0js3X7pcb7bp32ux97PMjy6PnKG/4pnx8im3 Q1YYCu6NylNZuiaKR3N3c1DCqTtNXS/S8+y7J92Ud2/R9zOUUVzPK9oebP+d5Wvs5Pub7r8q efrn4pW/Lx0VT30p+OTk6dt3Yeact5WmjHO5Xz33X6ix4eZLtqUJSizFGYmGWsxFxYkAsE4G KpACAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1699 Lines: 33 Hello! > > So, i see several possible ways to solve this: > > > > 1. Introduce some mechanism which would allow the driver to tell the kernel that it needs > > coherent pool of large size. Can be problematic because the driver can be a module, and pool > > allocation happens early. > > 2. Can we use some other method for allocating queues, which would not require such a huge > > coherent pool? > > 3. The driver could check value of atomic_pool_size and adjust own memory requirements > > accordingly. This indeed looks like a quick hack, but would at least make things running > > quickly. > > I have also noticed that CONFIG_DMA_CMA is turned off in my kernel. I guess it was a leftover > from old defconfig, because i carry over my .config from version to version. I enabled it and > rebuilt the kernel, but in order to get the driver working with this patch i had to also add > cma=32M option to kernel arguments. With default of 16M the allocation still fails. > Should we add Kconfig dependencies? After getting it working in guest i tried to apply it to host. With total of 128 virtual functions (= 128 interfaces) it does not work at all. Even after bumping cma region size to insane value of 2GB more than half of interfaces still failed to allocate queues. And after setting cma=3G i could not mount my rootfs. So, absolute NAK, unfortunately. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/