That supposes that the cost of the checking everywhere for borders needed
for these few frames outweights the cost of the occasionally copies. It
certainly didnt seem to for ethernet and smaller systems - remember IP
headers can be split across fragments as can other headers to an almost
arbitary depth - I've seen routing loops create
IP in IP in IP in IP in IP in IP in IP ... -> 65530 byte log frame
packets.
> reception is definitly a multi-CPU issue (one CPU takes the actual
> interrupt and creates the packet, but it's very possible that the packet
> will be used on another CPU).
It is far better at least on Intel that we don't do that - the cross cache
copy is expensive.
> We don't handle SMP tlb's 100% correctly even for the _normal_ cases right
> now - don't tell me it would be simple to fix the problems when you have
> interrupt driven events that touch the TLB too. That's where I just say
> "NO" (you can try to convince me, but you'll have a hard and rocky path
> doing that).
I dont think it will be easy to do that.
> For large packets (not fragments) we'll have to look into something else,
> and it's possible that we could have some kind of "fragment list" for it.
> That wouldn't be too hard, if only the upper layers knew of the
> possibility that the packet (not the header) would be in multiple parts.
The header can be in multiple parts. Also stuff like the NFS rpc code would
need a rewrite to cope with fragmented rpc headers
Alan