From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) by dpdk.org (Postfix) with ESMTP id 5F4722952 for ; Thu, 22 Sep 2016 07:07:48 +0200 (CEST) Received: by mail-io0-f175.google.com with SMTP id m186so74774741ioa.2 for ; Wed, 21 Sep 2016 22:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k+xf31ByQH8Sca6S5a6qxRhnPAUFJs/ipGaZjMHSQVY=; b=DF9yiEjAhV4eB2YZFZoKw2p6Hk7BRJXXJIqhVYHakFvDAPae+O4mV1F5HWII5HsYud yTh6naUbe3a/4braodnfZzGRZ7fauz4KbC5vCUgA1GidwH1pTa9tWAd6xe2zVbsnTZtq 4NZ5eJZKr5y7uQuKlRnsC+rvgfQFQgKsrRnIFbhfyeU73/4R7sCrJsTJwdLy+jFPPGyc 1Qbjb2NfetQfN80sclEyh01WDc6tII9YdVw86w/qt3QkG6hIerq2B+4fbcQ1PNm8A6Ki zbJFA3jBCXVP+/gSUfSzITlaC6di6VQdJjTM612+ypqLomrYBIqaFhgg8y/wh1ojZA1d 3SLg== 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:from:date :message-id:subject:to:cc; bh=k+xf31ByQH8Sca6S5a6qxRhnPAUFJs/ipGaZjMHSQVY=; b=OL5b7I5dzQt8ir/PNaghKlJXey7mqpEDUh3B529w6FwWDJMPxGKEmIehy9vGIJaP00 Nq0APULDXPCi8ACSKJzyd8I4Ssc90f7nnSPVgmj57KTEk1uUNWGVVxftKErvapH+7cUR R3yeb4PaS0M5wZhDbL5CzctK0O4taRcAsYO8aCMYxdbzjNxBpZitkpvQt01iUJdPrah9 sar8qhOS1rZLXRR9W8Fqr90DniBKw//yhWKfJIhAo+D2ANzt5z3HOVDEPXXM0dSYYukN rbqvk3XxHjuyeYeWvZyf6dL/kZwMBcHETzrZ+cQNWLA42LBATHgTFFsVB3TFeeaaM0KN lz+w== X-Gm-Message-State: AE9vXwMY8R7tug1gBGS4+qxrDGNDQXTqJZvAcRuF+MUbAEtMc7CEc5BY8fEBztsKSV5F05YNd+NbmxvYATToyA== X-Received: by 10.107.171.133 with SMTP id u127mr700089ioe.102.1474520867699; Wed, 21 Sep 2016 22:07:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.47 with HTTP; Wed, 21 Sep 2016 22:07:46 -0700 (PDT) In-Reply-To: <20160922015034.GA10277@mhcomputing.net> References: <20160919212257.GA27713@mhcomputing.net> <3263960.cPWMKkvuZx@xps13> <20160921172905.GA7158@mhcomputing.net> <20160921164205.000645d8@xeon-e3> <20160922015034.GA10277@mhcomputing.net> From: Stephen Hemminger Date: Wed, 21 Sep 2016 22:07:46 -0700 Message-ID: To: Matthew Hall Cc: Thomas Monjalon , "dev@dpdk.org" , Nikita Kozlov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] LPM6 next hop size 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: Thu, 22 Sep 2016 05:07:48 -0000 If you have 2G of huge memory and one 16M routes then the rules start to kill an application. Since huge memory is unpageable (pinned) then it is limited. On Wed, Sep 21, 2016 at 6:50 PM, Matthew Hall wrote: > On Wed, Sep 21, 2016 at 04:42:05PM -0700, Stephen Hemminger wrote: > > This was intentional because rte_malloc comes out of huge page area and > that > > resource is a critical resource. It could use rte_malloc() but that > makes it > > more likely to break when doing Policy Based routing or VRF. > > Can we get more clarity on why PBR or VRF would break it? The performance > and > fragmentation of the default glibc allocator are quite bad. So I am trying > to > avoid it in my app for example. > > Matthew. >