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: Sun, 27 Mar 2005 00:18:13 -0800
Cc: mpm@xxxxxxxxxxx, andrea@xxxxxxx, michaelc@xxxxxxxxxxx, James.Bottomley@xxxxxxxxxxxxxxxxxxxxx, ksummit-2005-discuss@xxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20050326235712.25f9ca36.davem@xxxxxxxxxxxxx>
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> <1111907130.4753.32.camel@mylaptop> <20050326235712.25f9ca36.davem@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Sat, 2005-03-26 at 23:57 -0800, David S. Miller wrote:
> On Sat, 26 Mar 2005 23:05:30 -0800
> Dmitry Yusupov <dmitry_yus@xxxxxxxxx> wrote:
> 
> > > During these gaps in time, you will need to keep your HW receive
> > > ring populated with packets.
> > 
> > ethernet flow-control must take care this case.
> > 
> > If driver's replenish logic could mix alloc_skb/netif_rx and SKB
> > recycling than pause frames should never happen even with gige+
> > interfaces.
> 
> I don't see what the big deal is if pause frames
> are generated when the system is low on atomic memory
> and RX allocations thus fail.

not a big deal may be. but. very interesting case when OOM causing
paging in/out and swapping device are on the same network under iSCSI
control. (disk-less setups) having reliable receive in that case is
important for making progress for READ operations.

> SKB recycling doesn't get the user on the cpu faster
> to receive the data.  I don't understand how you expect
> the recycling to be guarenteed except perhaps as a special
> case for iSCSI taking in the TCP packets in the ->data_ready()
> callback.  In that case it's exactly that, a special case
> hack, and not something generically useful at all.

right. this is what Open-iSCSI project is using for READs.


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