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

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

[Matthew Hall]

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.

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

[Bruce Richardson]

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

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

[Matthew Hall]

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.