[Top] [All Lists]

Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics
From: Matt Mackall <mpm@xxxxxxxxxxx>
Date: Tue, 29 Mar 2005 15:25:45 -0800
Cc: Rik van Riel <riel@xxxxxxxxxx>, Dmitry Yusupov <dmitry_yus@xxxxxxxxx>, Andi Kleen <ak@xxxxxx>, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>, andrea@xxxxxxx, michaelc@xxxxxxxxxxx, open-iscsi@xxxxxxxxxxxxxxxx, ksummit-2005-discuss@xxxxxxxxx, netdev <netdev@xxxxxxxxxxx>
In-reply-to: <1112137210.1088.17.camel@xxxxxxxxxxxxxxxx>
References: <1111905181.4753.15.camel@mylaptop> <20050326224621.61f6d917.davem@xxxxxxxxxxxxx> <Pine.LNX.4.61.0503272245350.30885@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <m1zmwn21hk.fsf@xxxxxx> <1112027284.5531.27.camel@mulgrave> <20050329152008.GD63268@xxxxxx> <1112116762.5088.65.camel@beastie> <1112130512.1077.107.camel@xxxxxxxxxxxxxxxx> <Pine.LNX.4.61.0503291659290.15625@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <1112137210.1088.17.camel@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Tue, Mar 29, 2005 at 06:00:11PM -0500, jamal wrote:
> On Tue, 2005-03-29 at 17:00, Rik van Riel wrote:
> >   However, we often will need
> > to get the packets off the network card before we can decide
> > whether or not they're high priority.
> True - although one could argue that with NAPI that decision would be a
> few opcodes away if you install the ingress qdisc. 
> So you may end up allocing only to free a few cycles later. Increased
> memory traffic but the discard happens sufficiently early for a s/ware
> only solution and CPU cycles not burnt as much.

I think we first need a software solution that makes no special
assumptions about hardware capabilities.
> > Also, there can be multiple high priority sockets, and we
> > need to ensure they all make progress.  Hence the mempool
> > idea.
> Sorry missed the early part of this thread: mempool is some
> strict priority scheme for mem allocation?

A mempool is a private allocation pool that attempts to maintain a
reserve of N objects. Various users in the kernel already. See

> For Sockets: If there was a "control" arbitrator preferably in user
> space which would install - after a socket open - both network ingress
> and/or egress rules for prioritization then wouldnt that suffice?

Generally, we don't want any special handling except when we're
effectively OOM.

Mathematics is the supreme nostalgia of our time.

<Prev in Thread] Current Thread [Next in Thread>