From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.46.186]) by dpdk.org (Postfix) with ESMTP id BFBF03777 for ; Wed, 1 Jul 2015 17:59:16 +0200 (CEST) Received: from [192.168.1.160] (99-34-229-174.lightspeed.sntcca.sbcglobal.net [99.34.229.174]) by mail.mhcomputing.net (Postfix) with ESMTPSA id ED2AD80C502; Wed, 1 Jul 2015 08:56:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Matthew Hall In-Reply-To: <20150701112028.GC2480@bricha3-MOBL3> Date: Wed, 1 Jul 2015 08:59:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C26251B-5027-449A-9CDB-17D7D0B5E8CA@mhcomputing.net> References: <7229FFD6-0C9B-4D8B-851C-16080A8C34B4@mhcomputing.net> <20150701112028.GC2480@bricha3-MOBL3> To: Bruce Richardson X-Mailer: Apple Mail (2.1878.6) 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 15:59:17 -0000 On Jul 1, 2015, at 4:20 AM, Bruce Richardson = wrote: > 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] Here is a view of the specific commits: https://github.com/megahall/dpdk_mhall/compare/megahall/lpm-expansion I'll work on emails when I get a moment. I was hoping since the branch = is open to all for download someone could sync it and try it in an = environment that has some kind of performance tests / known results for = the self-tests as my development setup is not that great compared to = some of the other DPDK engineers out there. > 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. Sounds good. > 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? I think this could be pretty nice, the tricky part is that, at least in = the version Vladimir and Stephen helped me cook up, a lot of bitfield = trickery was involved. So we'd need to switch away from bitfields to = something a bit more flexible or easy to work with when variable = configuration comes into the picture. Also not sure how it'd work at = runtime versus compilation, etc. You guys know more than me about this = stuff I think. Matthew.