Re: Regarding Kirkwood cpu support
What kind of time frames are we talking about when it comes to Debian
support for Kirkwood for us "ordinary users" who don't compile our own
kernels and want our machine to start every day, every time?
Will initial support consist of install packages from Martin or
others, and official Debian support be available only in Debian
The reason I am asking is that I am thinking "Should I buy a
SheevaPlug now or wait a couple of months?"
On Tue, Mar 17, 2009 at 10:30, Lennert Buytenhek <email@example.com> wrote:
> On Tue, Mar 17, 2009 at 09:34:18AM +0100, Thomas Boehne wrote:
> > > On the 6281 at 1.2 GHz, I get wire speed TCP transmit when GSO is
> > > enabled, and wire speed TCP receive when LRO is enabled (which
> > > mv643xx_eth supports since recently -- it's currently in net-next).
> > Wirespeed sounds extremely interesting. I guess the CPU load is
> > near 100% then, correct? Thanks for your input so far.
> CPU load on wire speed TCP receive is ~70% when copying everything
> to userspace (i.e. a userland recv() loop on the socket). When
> discarding all the data in kernelspace (e.g. splice() to /dev/null,
> with a hack to make sure that the linear part of skbuffs doesn't get
> copied into a separate area first or with a patch to make mv643xx_eth
> receive into pages), it's closer to ~30%. This are measured with
> cyclesoak with MTU=1500, and are pretty consistent.
> CPU load on wire speed TCP transmit is pretty variable, due to GSO
> behaving eratically when there isn't enough CPU to transmit wire
> speed without using GSO. (I.e. it seems that GSO will always converge
> into a stable state where it will saturate the wire at the same low CPU
> usage if the CPU is powerful enough to transmit wire speed without using
> GSO, but if you only get ~90MB/s-ish without using GSO, it seems that
> there are different stable states you can get into depending on
> burstiness of ACKs from the other side and some other factors. So
> sometimes it converges to 2 "real" segments per GSO skbuff and stays
> there, sometimes to 3 "real" segments per GSO skbuff, etc.) I sent
> some emails about this to netdev@ some time ago, but didn't find a
> good way of dealing with this yet.
> To UNSUBSCRIBE, email to debian-arm-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org