Re: [dpdk-dev] rte_lpm4 with expanded next hop support now available

[Matthew Hall <mhall@mhcomputing.net>]

On Jul 1, 2015, at 4:20 AM, Bruce Richardson <bruce.richardson@intel.com> 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.