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 D2382C562 for ; Wed, 24 Jun 2015 06:15:51 +0200 (CEST) Received: by mail.mhcomputing.net (Postfix, from userid 1000) id B5A5F80A264; Tue, 23 Jun 2015 21:13:14 -0700 (PDT) Date: Tue, 23 Jun 2015 21:13:14 -0700 From: Matthew Hall To: Vladimir Medvedkin Message-ID: <20150624041314.GA15524@mhcomputing.net> References: <5A3882CB-0DE0-43DB-8DCA-051D561AA943@mhcomputing.net> <20150622175302.GA15788@mhcomputing.net> <20150622235102.41c3619a@uryu.home.lan> <20150623063024.GA3458@mhcomputing.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "" Subject: Re: [dpdk-dev] rte_lpm with larger nexthops or another method? 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, 24 Jun 2015 04:15:52 -0000 On Tue, Jun 23, 2015 at 10:19:58AM +0300, Vladimir Medvedkin wrote: > Hi all, > > Matthew, I think ipv6 lpm code need less changes > struct rte_lpm6_tbl_entry { > uint32_t next_hop: 21; /**< Next hop / next table to be > checked. */ > uint32_t depth :8; /**< Rule depth. */ > > /* Flags. */ > uint32_t valid :1; /**< Validation flag. */ > uint32_t valid_group :1; /**< Group validation flag. */ > uint32_t ext_entry :1; /**< External entry. */ > }; > there already is 21 bit for next_hop (need chenge only for rte_lpm6_rule) > In Stephen approach for next_hop given only 16 bits, this is enough for > next hop index, but not enough for AS number that originate prefix. > > Regards, > Vladimir Vladimir, One thing I was confused, you published the changes to rte_lpm_tbl24_entry but you didn't say what you did to change rte_lpm_tbl8_entry, as that one only had an 8-bit next_hop as well. I wanted to be sure I didn't change it wrong and break something. Hopefully Stephen can make his bug fixes available so I could add all of this together and try to make a patchset for dpdk-next to test it all out. Would be a huge win compared to all the crappy LPM code I found on the Internet. Matthew.