Andre Oppermann writes:
>
> I have already the next round in the works which is optimized even more
> by merging consecutive mbuf chains together (at the moment I have packet
> segment chains which have a direct pointer to the mbuf at the end of the
> chain) and which get passed in one go t
Andrew Gallatin wrote:
>
> Andre Oppermann writes:
> >
> > I've got some excellent review feedback from Mike Spengler and he found
> > a off-by-one queue limit tracking error.
> >
> > http://www.nrg4u.com/freebsd/tcp_reass-20041213.patch
> >
>
> Here are the same tests running your new pa
Andre Oppermann writes:
>
> I've got some excellent review feedback from Mike Spengler and he found
> a off-by-one queue limit tracking error.
>
> http://www.nrg4u.com/freebsd/tcp_reass-20041213.patch
>
Here are the same tests running your new patch in comparison to a
stock 6.x kernel
Andre Oppermann wrote:
I've totally rewritten the TCP reassembly function to be a lot more
efficient. In tests with normal bw*delay products and packet loss
plus severe reordering I've measured an improvment of at least 30% in
performance. For high and very high bw*delay product links the
perform
Andre Oppermann writes:
>
> Regarding your measurements, did you measure the bandwidth as reported
> by Netperf? Is a FreeBSD box on both sides (you mentioned Linux)?
Yes, all the numbers were in Mb/sec. The sender was running
linux-2.6.6 (also SMP on a single HTT P4).
Drew
_
Andrew Gallatin wrote:
>
> Andre Oppermann writes:
> > I've totally rewritten the TCP reassembly function to be a lot more
> > efficient. In tests with normal bw*delay products and packet loss
> > plus severe reordering I've measured an improvment of at least 30% in
> > performance. For high
Andre Oppermann writes:
> I've totally rewritten the TCP reassembly function to be a lot more
> efficient. In tests with normal bw*delay products and packet loss
> plus severe reordering I've measured an improvment of at least 30% in
> performance. For high and very high bw*delay product lin
I've totally rewritten the TCP reassembly function to be a lot more
efficient. In tests with normal bw*delay products and packet loss
plus severe reordering I've measured an improvment of at least 30% in
performance. For high and very high bw*delay product links the
performance improvement is mos
