On Sun, 13 Jul 2003 16:53:23 PDT, "David S. Miller" said:

> I really don't see why receive is so much of a big deal
> compared to send, and we do a send side version of this
> stuff already with zero problems.

Well.... there's optimizations you can do on the send side..

> The NFS code is already basically ready to handle a fragmented packet
> (headers + pages), and could stick the page part into the page cache
> easily on receive.

For example, in this case, you know a priori what the IP header will look
like, so you can use tricks like scatter-gather to send the header from one
place and a page-aligned data buffer from another, or start the packet at
(page boundary - IP_hrd_len), or tricks of that sort.  In 20 years, I've seen
a lot of vendors do a lot of ugly things to speed up their IP stack, often
based on the fact that they knew a lot about the packet before they started
assembling it.

It's hard to do tricks like that when you don't know (for instance) how
many IP option fields the packet has until you've already started sucking
the packet off the wire - at which point either the NIC itself has to be clever
(Hmm, there's that IP offload again) or you have literally about 30 CPU cycles
to do interrrupt latency *and* decide what to do....