Thread (73 messages) 73 messages, 14 authors, 2005-03-31

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

From: Dmitry Yusupov <hidden>
Date: 2005-03-27 07:05:30

Possibly related (same subject, not in this thread)

On Sat, 2005-03-26 at 22:46 -0800, David S. Miller wrote:
On Sat, 26 Mar 2005 22:33:01 -0800
Dmitry Yusupov [off-list ref] wrote:
quoted
i.e. TCP stack should call NIC driver's callback after all SKB data
been successfully copied to the user space. At that point NIC driver
will safely replenish HW ring. This way we could avoid most of memory
allocations on receive.
How does this solve your problem?  This is just simple SKB recycling,
and it's a pretty old idea.
I know. it is very old idea.
TCP packets can be held on receive for arbitrary amounts of time.
I'm thinking about mixing existing way of doing things with guarantied
SKB recycling. It should help to storage stacks to make a progress on
receive at least.
This is especially true if data is received out of order or when
packets are dropped.  We can't even wake up the user until the
holes in the sequence space are filled.

Even if data is received properly and in order, there are no hard
guarentees about when the user will get back onto the CPU to
get the data copied to it.

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help