Jeff McAdams wrote:
Add a set of "indent" rules to the source package, and just make sure that people run "indent" with those rules before checking in new versions of their code.
Yeah, I ran indent over the whole repo around about 0.65 days...alas, I don't remember the options I used with it...I'll have to go back and recreate that...I remember it wasn't stock indent options, though. :/ Once I recreate those, I'll add some sort of file indicating what they are so people can use that.
I'm a little concern with the removal of the padding handling.
Missed the details there - is that where the code is adjusted to just skip 6 bytes here and there? That's on my list of things to read over in my copious spare time :)
Nope, the skipping the 6 bytes is legit...that's typically skipping over the AVP header to get at the actual data.
What I was talking about looks like it skips over the padding field in the overall packet header, preferring, instead, to use the offset value to align the data in the packet on word boundaries. While there's an efficiency gain...we need to be prepared to handle packets coming from peers that use either.
One thing I have noticed is that Cisco injects "Offset" to make the data fields start on a longword boundary (32 bits). I'd like to know what the difference in efficiency is between sending Cisco IOS products L2TP packets with "Offset" versus the current implementation of "Length" - they both achieve the same result, but I suspect that "Length" will incur processing overheads as the Cisco has to check that the Length is correct. But I don't have Cisco equipment to test against.
The big deal is that some hardware architectures are considerably more efficient access memory if the accesses are word aligned...that's the point of using the offset. I'm not sure how much overhead there is on these types of architectures, however.
But.. but.. I'm emotionally attached to the l2tpd code now! :)
You think *you're* emotionally attached! :) Seriously, though...this code base is just so bad overall...it just wasn't written with a clear understanding of how to move forward to accomplish some of the things that were originally goals to accomplish with this code base (both to work as a more traditional LAC, and to eventually support kernel handling...neither will be at all easy to do with this code base)
By the time kernel support is properly implemented, the code will look nothing at all like the current codebase - so we may as well pick one that needs work anyway ;)
I'm not sure its an issue of just "needing work." I think its more of an issue of "you can't get there from here." :) If you did, you'd essentially be re-writing the whole thing anyway, I believe, so you might as well start from scratch.
-- Jeff McAdams "He who laughs last, thinks slowest." -- anonymous
pgp00000.pgp
Description: PGP signature
