[Top] [All Lists]

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

To: Rik van Riel <riel@xxxxxxxxxx>
Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics
From: Matt Mackall <mpm@xxxxxxxxxxx>
Date: Tue, 29 Mar 2005 14:17:43 -0800
Cc: jamal <hadi@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: <Pine.LNX.4.61.0503291659290.15625@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <20050327054831.GA15453@xxxxxxxxx> <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>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Tue, Mar 29, 2005 at 05:00:35PM -0500, Rik van Riel wrote:
> On Tue, 29 Mar 2005, jamal wrote:
> > If yes, the solution maybe to just drop all non-high-prio packets coming
> > in during the denial of service attack (for lack of better term). In
> > other words some strict prioritization scheduling (or rate control) at
> > the network level either in the NIC or ingress qdisc level.
> Exactly, that is the proposal.  However, we often will need
> to get the packets off the network card before we can decide
> whether or not they're high priority.
> Also, there can be multiple high priority sockets, and we
> need to ensure they all make progress.  Hence the mempool
> idea.

I'm sure Rik realizes this, but it's important to note here that
"making progress" may require M acknowledgements to N packets
representing a single IO. So we need separate send and acknowledge
pools for each SO_MEMALLOC socket so that we don't find ourselves
wedged with M-1 available mempool slots when we're waiting on ACKs. So
accounting ACK packets to the appropriate receiver once we've figured
out what socket an ACK is intended for is critical.

Note that ACK here is the application layer command result that needs
to be propagated back to the driver (and possibly higher in the case
of things like CD writing over iSCSI) and not simply a bit in the TCP

Mathematics is the supreme nostalgia of our time.

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