netdev
[Top] [All Lists]

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

To: "open-iscsi@xxxxxxxxxxxxxxxx" <open-iscsi@xxxxxxxxxxxxxxxx>
Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics
From: Dmitry Yusupov <dmitry_yus@xxxxxxxxx>
Date: Mon, 28 Mar 2005 08:37:40 -0800
Cc: Rik van Riel <riel@xxxxxxxxxx>, mpm@xxxxxxxxxxx, andrea@xxxxxxx, michaelc@xxxxxxxxxxx, James.Bottomley@xxxxxxxxxxxxxxxxxxxxx, ksummit-2005-discuss@xxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <m1zmwn21hk.fsf@xxxxxx>
References: <4241D106.8050302@xxxxxxxxxxx> <20050324101622S.fujita.tomonori@xxxxxxxxxxxxx> <1111628393.1548.307.camel@beastie> <20050324113312W.fujita.tomonori@xxxxxxxxxxxxx> <1111633846.1548.318.camel@beastie> <20050324215922.GT14202@xxxxxxxxxxxxxx> <424346FE.20704@xxxxxxxxxxx> <20050324233921.GZ14202@xxxxxxxxxxxxxx> <20050325034341.GV32638@xxxxxxxxx> <20050327035149.GD4053@xxxxxxxxx> <20050327054831.GA15453@xxxxxxxxx> <1111905181.4753.15.camel@mylaptop> <20050326224621.61f6d917.davem@xxxxxxxxxxxxx> <Pine.LNX.4.61.0503272245350.30885@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <m1zmwn21hk.fsf@xxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Mon, 2005-03-28 at 18:12 +0200, Andi Kleen wrote:
> Rik van Riel <riel@xxxxxxxxxx> writes:
> >    one for sending and one for receiving
> > 2) have a global emergency mempool available to receive network
> >    packets when GFP_ATOMIC fails - this is useful since we don't
> >    know who a packet is for when we get the NIC interrupt, and
> >    it's easy to have just one pool to check
> 
> This does not work because mempools assume you can sleep,
> and in most NIC drivers you cant while doing RX refill.
> The NIC drivers can be rewritten to do this refilling in
> a workqueue. But it is not clear it is useful anyways because
> Linux failing to allocate a buffer is no different from
> the network overflowing the hardware queue of the network
> device, which Linux cannot do anything about. 
> 
> Basically a network consists of lots of interconnected
> queues, and even if you try to make the Linux specific
> side of the queue reliable there are lots of other queues
> that can still lose packets.
> 
> With TCP that is no problem of course because in case of 
> a packet loss the packet is just retransmitted. 
> 
> So in short using mempools on receiving is not needed.
> 
> Now memory allocation for writing is a different chapter.
> You cannot recover from a lost writing.
> The kernel currently goes even in endless loops in this
> case (e.g. on TCP FIN allocation)
> 
> With the exception of routing the allocation fortunately 
> usually happens there in:
> - socket context: great you can use a per socket mempool
> - thread context: you can sleep
> 
> With routing that is not the case, but it does not matter
> because it typically does not allocate new packets, but
> just sends out existing ones.
> 
> In short you need mempool only for TX. With some luck you even only
> need them for the skbuff head and a small header buffer, since I would
> expect iscsi TX to be typically zero copy for data and just passing
> struct page *s around.

that's always true for Open-iSCSI and for sfnet in FFP(rcf3720) but not
for other implementations. moreover, if NIC does not support
checksumming on Tx than sendpage() interface will fail to sendmsg()
which will allocate new skb each time.




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