From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 85DF5ADA7 for ; Wed, 1 Jul 2015 13:20:32 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 01 Jul 2015 04:20:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,385,1432623600"; d="scan'208";a="756454256" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.162]) by orsmga002.jf.intel.com with SMTP; 01 Jul 2015 04:20:31 -0700 Received: by (sSMTP sendmail emulation); Wed, 01 Jul 2015 12:20:29 +0025 Date: Wed, 1 Jul 2015 12:20:29 +0100 From: Bruce Richardson To: Matthew Hall Message-ID: <20150701112028.GC2480@bricha3-MOBL3> References: <7229FFD6-0C9B-4D8B-851C-16080A8C34B4@mhcomputing.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7229FFD6-0C9B-4D8B-851C-16080A8C34B4@mhcomputing.net> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "" Subject: Re: [dpdk-dev] rte_lpm4 with expanded next hop support now available 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: Wed, 01 Jul 2015 11:20:33 -0000 On Tue, Jun 30, 2015 at 11:18:35PM -0700, Matthew Hall wrote: > Hello, > > Based on the wonderful assistance from Vladimir and Stephen and a close friend of mine that is a hypervisor developer who helped me reverse engineer and rewrite rte_lpm_lookupx4, I have got a known-working version of rte_lpm4 with expanded 24 bit next hop support available here: > > https://github.com/megahall/dpdk_mhall/tree/megahall/lpm-expansion > > I'm going to be working on rte_lpm6 next, it seems to take a whole ton of memory to run the self-test, if anybody knows how much that would help, as it seems to run out when I tried it. > > Sadly this change is not ABI compatible or performance compatible with the original rte_lpm because I had to hack on the bitwise layout to get more data in there, and it will run maybe 50% slower because it has to access some more memory. > > Despite all this I'd really like to do the right thing find a way to contribute it back, perhaps as a second kind of rte_lpm, so I wouldn't be the only person using it and forking the code when I already met several others who needed it. I could use some ideas how to handle the situation. > > Matthew. Could you maybe send a patch (or set) with all your changes in it here for us to look at? [I did look at it in github, but I'm not very familiar with github and the changes seem to be spread over a whole series of commits] In terms of ABI issues, the overall function set for lpm4 library is not that big, so it may be possible to maintain old a new copies of the functions in parallel for one release, and solve the ABI issues that way. I'm quite keen to get these changes in, since I think being limited to 255 next hops is quite a limitation for many cases. A final interesting suggestion I might throw out, is: can we make the lpm library configurable in that it can use either 8-bit, 16/24 bit or even pointer based next hops (I won't say 64-bit, as for pointers we might be able to get away with less than 64-bits being stored)? Would such a thing be useful to people? Regards, /Bruce