Messages in this thread | | | Date | Tue, 15 Jan 2008 16:17:05 +0100 | From | Radoslaw Szkodzinski (AstralStorm) <> | Subject | Re: questions on NAPI processing latency and dropped network packets |
| |
On Tue, 15 Jan 2008 08:47:07 -0600 "Chris Friesen" <cfriesen@nortel.com> wrote:
> Jarek Poplawski wrote: > > > IMHO, checking this with a current stable, which probably you are going > > to do some day, anyway, should be 100% acceptable: giving some input to > > netdev, while still working for yourself. > > While I would love to do this, it's not that simple. > > Some of our hardware is not supported on mainline, so we need per-kernel > version patches to even bring up the blade. The blades netboot via a > jumbo-frame network, so kernel extensions are needed to handle setting > the MTU before mounting the rootfs.
Why? Can't you use a small initramfs to set it up?
> The blade in question uses CKRM > which doesn't exist for newer kernels so the problem may simply be > hidden by scheduling differences.
Current spiritual successor is Ingo's realtime patchset I guess.
> The userspace application uses other > kernel features that are not in mainline (and likely some of them won't > ever be in mainline--I know because I've tried).
What would these be? Some proc or sysfs files that were removed or renamed? Maybe they can be worked around w/o changing the application at all, or very minor changes.
Also, be sure to check if there are pauses with other CPU hogs.
> Basically, the number of changes required for our environment makes it > difficult to just boot up the latest kernel.
Yes, adding an initramfs is non-trivial (some busybox + shell scripting), but not all that hard either. And maintaining one is easier than patching the kernel. (usually 0 maintenance, maybe minor fixes sometimes) [unhandled content-type:application/pgp-signature] | |