Hi all, 2015-10-30 20:59 GMT+03:00 Matthew Hall <mhall at mhcomputing.net>:
> On Fri, Oct 30, 2015 at 12:00:18PM +0000, Bruce Richardson wrote: > > Matthew's patches were attachments, I don't think they came through in > patchwork > > correctly :-(, but that is the relevant link there anyway.] > > Let me know if there is something I can do better there. I was having a > difficult time figuring out how to preserve the thread ID in the middle of > the > thread and not cause a new thread. The git email workflows are very > confusing > and I figured it was better to send something as soon as I could. > > > * Some patches increase the next-hop to 16 bits, others to 24-bits. In > both cases > > a single entry still only occupies 32-bits, so can be read/written to > > atomically > > I went with 24 because it was the biggest amount I could get that still had > this property. > > > * Only Michal's set appears to take into account ABI versioning, which is > > a difficult problem for this lib, with inlined functions. > > Agreed. His patches are the most professional from this perspective. This > is > why I was trying to contribute to you and to him so we get the most > professional result for the customers. > > > * Matthew's patchset moves the lookup functions to be non-inlined, which > will > > make future updates easier from ABI compatibility - at the cost of > lookup > > performance. > > This point is optional for me. I did it, because without it, it was totally > impossible for me to work on the code in a debugger as I am a security > engineering guy not a crazy embedded C coder or kernel hacker. > > > * Vladimir's patchset merges in the tbl24 and tbl8 entries into a single > data > > type. > > I really liked this feature of Vladimir's patches, it makes it easier to > maintain and less confusing. I had a lot of headaches keeping all those > structs straight with the separate types, but I didn't know we had the > chance > for a great big MEGA-REFACTOR. I love this community! > > > * That patchset also introduces an extra optional 32-bit field "as_num", > allowing > > 64-bit lpm table entries - obviously at a cost of increased > memory/cache > > footprint. > > Is there a way we could test it? Vladimir, did you test the performance? If > so, what happened? > Performance regression depends on the traffic pattern and cache size. > > > * Stephen's patchset includes a range of other fixes e.g. for more > efficient > > management of the rules array, and dynamic allocation of the TBL8s. > > * Matthew's patchset also includes change to LPM for IPv6, which I'm > considering > > out-of-scope for now, so as to focus on LPM v4 only. > > Any chance that is inconsistent betwen LPM4 and LPM6 really hoses me, > because > I am writing green-field code which treats both protocols as first-class > citizens and I'd really not like to have totally inconsistent and inferior > support in one versus the other. > > > * Increase next hops to be the full 24 bits, so as to allow maximum > flexibility > > and not waste the extra 8 bits of space in the 32-bit entries. > > +1 > +1. Split of next hop and forwarding class I can do in app logic. > > > * Move the lookup functions which work on multiple packets to be > non-inlined > > Open to opinions on the performance of this. I am not an expert on this > area. > > > * Merge in the tbl24 and tbl8 structures to make the code that little > bit shorter > > +1 > > > * Look to pull in as many of Stephen's other improvements as possible - > though > > this may be in a separate patchset to the other changes. > > +1. Perhaps if we get a pre-release on a branch with everything else, we > could > see if Stephen is willing to rebase his non-duplicate changes. > > > * I'm uncertain as to the extra 32-bit as_num field. Adding it as an > extra > > #define is trivial, but adds to the compile-time config. Having it as > a run-time > > option is possible, but likely will make the code a lot more > complicated, as > > we no longer have arrays of a fixed size. > > > > Naturally, with whatever solution is come up with, ABI compatibility > must be > > taken into account and functions versionned appropriately! > > Normally I am not a big define guy. But it seems like a define is good > here. > Somebody is going to need to know beforehand if they are making a Core > Router > where they want this, or a Security Inspection system like mine, etc. > For example in case of core router as_num feature can be necessary for netflow. It can be necessary in case of security device such as my ddos mitigation system. > > So it seems easier than doing a bunch of crazy size-juggling in the code. > > > do we want to have some of these changes in 2.2? > > Personally I am OK to wait as I have it working in my copy. I am just > trying > to be a good citizen of the community and contribute back when I see some > core > engineers going after the same code. > > In particular, for me, having LPM4 only with no LPM6 is not worth much so > I'd > be happy to wait for a single upgrade to both of them. > > > Matthew, Stephen, Vladimir, Michal, Thomas - thoughts on this? > > [do I accurately sum up the situation?] > > This email was top-quality and very well done by you guys. > > Matthew. > Regards, Vladimir