netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Chris Friesen" <cfriesen@nortel.com>
To: "Radoslaw Szkodzinski (AstralStorm)" <lkml@astralstorm.puszkin.org>
Cc: Jarek Poplawski <jarkao2@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: questions on NAPI processing latency and dropped network packets
Date: Tue, 15 Jan 2008 11:14:25 -0600	[thread overview]
Message-ID: <478CE9F1.8020409@nortel.com> (raw)
In-Reply-To: <20080115161705.0724250d@astralstorm.puszkin.org>

Radoslaw Szkodzinski (AstralStorm) wrote:
> On Tue, 15 Jan 2008 08:47:07 -0600
> "Chris Friesen" <cfriesen@nortel.com> wrote:

>>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?

Sure, if we changed our build system, engineered a suitable small 
userspace, etc.  At this point it's easier to maintain a small patch to 
the kernel dhcp parsing code so that we can specify mtu.

>>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.

I think the group scheduling stuff for CFS is closer, but there are 
design and API differences that would require us to rework our system.

>>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.

No, more than proc/sysfs.  Things like notification of process state 
change (think like SIGCHLD but sent to arbitrary processes), additional 
messaging protocol families, oom-killer protection, dirty page 
monitoring, backwards compatibility for "dcbz" on the ppc970, nested 
alternate signal stacks, and many others.  Between our kernel vendor's 
patches and our own, there are something like 600 patches applied to the 
mainline kernel.

> Also, be sure to check if there are pauses with other CPU hogs.

With the sctp hash patch applied we're now sitting with 45% cpu free on 
one cpu, and about 25% free on the other, and we're still seeing 
periodic bursts of rx fifo loss.  It's wierd.  Still trying to figure 
out what's going on.

Chris

  reply	other threads:[~2008-01-15 17:14 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-10 17:24 questions on NAPI processing latency and dropped network packets Chris Friesen
2008-01-10 17:37 ` Kok, Auke
2008-01-10 18:12   ` Chris Friesen
2008-01-10 18:26     ` Kok, Auke
2008-01-10 18:25 ` James Chapman
2008-01-10 21:29   ` Chris Friesen
2008-01-10 18:41 ` Rick Jones
2008-01-10 19:01   ` Kok, Auke
2008-01-11  1:20 ` David Miller
2008-01-11 14:59   ` Chris Friesen
2008-01-11 22:29     ` Herbert Xu
2008-01-12  1:53     ` David Miller
2008-01-14 15:58       ` Chris Friesen
2008-01-15  7:19         ` Jarek Poplawski
2008-01-15 14:47           ` Chris Friesen
2008-01-15 15:17             ` Radoslaw Szkodzinski
2008-01-15 17:14               ` Chris Friesen [this message]
2008-01-15 17:23                 ` Eric Dumazet
2008-01-15 20:29             ` Jarek Poplawski
2008-01-16  0:17               ` Herbert Xu
2008-01-16  6:58                 ` Jarek Poplawski
2008-01-16 20:04                   ` Willy Tarreau
2008-01-16 22:42                     ` Jarek Poplawski
2008-01-12  5:37 ` Ray Lee
2008-01-14 15:49   ` Chris Friesen
2008-01-14 16:56     ` Eric Dumazet
2008-01-14 19:25       ` Chris Friesen
2008-01-14 19:33         ` Eric Dumazet
2008-01-14 20:02           ` Chris Friesen
2008-01-15 15:09             ` Vlad Yasevich
2008-01-21 19:53 ` Chris Friesen
2008-01-21 21:11   ` Ben Greear
2008-01-21 23:15     ` Chris Friesen
2008-01-21 23:32       ` Ben Greear
2008-01-21 21:31   ` Eric Dumazet
2008-01-21 23:25     ` Chris Friesen
2008-01-22  5:46       ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=478CE9F1.8020409@nortel.com \
    --to=cfriesen@nortel.com \
    --cc=jarkao2@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@astralstorm.puszkin.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).