.. sounds like the beginning of a wiki page to me, describing the mini project, the latest status and the latest patch.
:) Adrian On 13 October 2012 11:32, Aleksandr Rybalko <r...@ddteam.net> wrote: > Gleb Smirnoff <gleb...@freebsd.org> написал(а): > >>On Fri, Oct 12, 2012 at 05:06:29PM -0400, Adrian Chadd wrote: >>A> On 12 October 2012 08:47, Gleb Smirnoff <gleb...@freebsd.org> wrote: >>A> > On Fri, Oct 12, 2012 at 04:46:40PM +0400, Gleb Smirnoff wrote: >>A> > T> Latest version of patch for further review and testing >>A> > T> Changelog: >>A> > T> - Fixed TCP checksums >>A> > T> - Added comment about raw sockets byte ordering. >>A> > T> - More explicit htons(0), when assigning ip_off field. >>A> >>A> I've just eyeballed the patch again: >>A> >>A> * You've patched SCTP and IGMP - have you done any SCTP and IGMP >>testing at all? >>A> * This kind of stuff almost begs for some kind of automated test >>suite >>A> for testing IPv4, IPv6, TCP/UDP/ICMP, IGMP, SCTP, all the tunneling >>A> stuff - is there anything out there like this? I know of the IPv6 >>test >>A> suites that exist; what about being able to regression test the >>other >>A> stuff? >> >>Not tested yet: >> >>SCTP >>IGMP >>IPSEC >>siftr(4) >>mrouting >>pfsync, pf_route() >>stf(4) >>ng_ipfw(4) > > No, ng_ipfw tested :-) > >> >>Tested: >> >>TCP/UDP/ICMP >>ip_fragment/ip_reass >>raw socket >>gre(4) as if_gre and as ng_pptpgre >>gif(4) >>pf(4) >>ipfw(4) >>divert(4) >> >>A> Also whilst I'm nitpicking - do you think there's any performance >>A> issues that may creep up? Remember that "performance issues" to me >>A> don't necessarily mean "on a current generation intel", but mean >>"all >>A> those cache starved ARM/MIPS/PPC/Atom boards out there that aren't >>A> natively in network byte order." Making everything use network byte >>A> order throughout the stack is nice for read-only packet work and >>nice >>A> for cache-happy i386s, but what about the rest of the world? >> >>Well, there may be unmeasurable impact. Just a few instructions per >>packet. Some functions may be optimized to store converted length in >>local variable and perform one or two ntohs() operations less. But >>better as a separate change. We've got much more fat optimization >>targets in stack than this. >> >>A> (Don't get me wrong, I think this tidy-up is very nice and maybe >>quite >>A> needed, I just wonder what other unknown magic is hiding behind the >>A> existing code..) >> >>There is so much magic here, and I want to just wipe it away instead >>of learning it to depths. The motivation to finally start this work and >>get it done is several panics due to packet in wrong byte order, which >>I >>am failing to parse and model out which codepath could lead to them. >>Thus >>I decided to fix that in principle. > > > WBW > ------ > Aleksandr Rybalko <r...@ddteam.net> > > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
