[Top] [All Lists]

Re: [Fwd: Re: possible bug x86 2.4.2 SMP in IP receive stack]

To: Bob Felderman <feldy@xxxxxxxx>
Subject: Re: [Fwd: Re: possible bug x86 2.4.2 SMP in IP receive stack]
From: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 9 Mar 2001 13:23:27 -0800 (PST)
Cc: kuznet@xxxxxxxxxxxxx, hadi@xxxxxxxxxx, ak@xxxxxx, andrewm@xxxxxxxxxx, netdev@xxxxxxxxxxx, pp@xxxxxxxxxxxxxx
In-reply-to: <Pine.SUN.4.21.0103091247280.11174-100000@xxxxxxxxxxxxxx>
References: <200103092035.XAA27248@xxxxxxxxxxxxx> <Pine.SUN.4.21.0103091247280.11174-100000@xxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Bob Felderman writes:
 > On Fri, 9 Mar 2001 kuznet@xxxxxxxxxxxxx wrote:
 > > _No_ copy on softirq. It is more important.
 > > 
 > > It is the reason why all the tricks with backlog are not essential.
 > Can you explain this a bit more? Are you saying that a softirq
 > will reduce the number of copies? Should the driver be calling
 > softirq to deliver the packets using netif_rx?

Network input packet processing (ie. whet the kernel first processes
input packets after you give them to netif_rx()) occur in softirq
context.  This is what Alexey is talking above.

Previously, IP input when seeing the final fragment of a packet,
would allocate a new linear SKB to fit the whole thing, then copy
each fragment into the new buffer.  This all occured in softirq

Now, a link list of the frags is just held onto, and later in _user_
context the individual frags are copied by hand into user space
or wherever appropriate.

Alexey is saying that moving the copy from network soft interrupt
processing into the user context is what is helping moreso than
the reduction in number of copies performed.

David S. Miller

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