Hi all, I also have LPM library implementation. Main points: - First, we don't need two separate structures rte_lpm_tbl8_entry and rte_lpm_tbl24_entry. I think it's better to merge in one rte_lpm_tbl_entry because there is only one difference in name of one bit - valid_group vs ext_entry. Let it's name will be ext_valid. - Second, I think that 16 bit is more than enough for next-hop index. It's better to use remaining 8 bits for so called forwarding class. It is something like Juniper DCU that can help us to classify traffic based on dst prefix. But after conversation with Bruce Richardson I agree with him that next-hop index and forwarding class can be split from one return value by the application. - Third, I want to add posibility to lookup AS number (or any other 4 byte) that originate that prefix. It can be defined like: union rte_lpm_tbl_entry_extend { #ifdef RTE_LPM_ASNUM uint64_t entry; #else uint32_t entry; #endif #ifdef RTE_LPM_ASNUM uint32_t as_num; #endif struct{ uint32_t next_hop :24;/**< next hop. */ uint32_t valid :1; /**< Validation flag. */ uint32_t ext_valid :1; /**< External entry. */ uint32_t depth :6; /**< Rule depth. */ }; }; - Fourth, extension of next-hop index is done not only for increasing of next-hops but also to increase more specific routes. So I think that should be fixed + unsigned tbl8_index = (uint8_t)ip + + ((uint8_t)tbl_entry * RTE_LPM_TBL8_GROUP_NUM_ENTRIES);
Regards, Vladimir 2015-10-23 21:38 GMT+03:00 Matthew Hall <mhall at mhcomputing.net>: > On Fri, Oct 23, 2015 at 09:33:05AM -0700, Stephen Hemminger wrote: > > On Fri, 23 Oct 2015 09:20:33 -0700 > > Matthew Hall <mhall at mhcomputing.net> wrote: > > > > > On Fri, Oct 23, 2015 at 03:51:48PM +0200, Michal Jastrzebski wrote: > > > > From: Michal Kobylinski <michalx.kobylinski at intel.com> > > > > > > > > The current DPDK implementation for LPM for IPv4 and IPv6 limits the > > > > number of next hops to 256, as the next hop ID is an 8-bit long > field. > > > > Proposed extension increase number of next hops for IPv4 to 2^24 and > > > > also allows 32-bits read/write operations. > > > > > > > > This patchset requires additional change to rte_table library to meet > > > > ABI compatibility requirements. A v2 will be sent next week. > > > > > > I also have a patchset for this. > > > > > > I will send it out as well so we could compare. > > > > > > Matthew. > > > > Could you consider rolling in the Brocade/Vyatta changes to LPM > > structure as well. Would prefer only one ABI change > > Hi Stephen, > > I asked you if you could send me these a while ago but I never heard > anything. > > That's the only reason I made my own version. > > If you have them available also maybe we can consolidate things. > > Matthew. >