VanLUG Email Archive
> Another area that chained buffers may help with is when you have
> alignment restrictions, such as on an Alpha processor. Some Ethernet
> cards insist on bringing in a full packet via DMA on an aligned
> boundary which, since the Ethernet header is 14 bytes long (Bob
> Metcalfe will go to hell for this. :-))
You mean on a page-aligned or cache-aligned boundary? That
kind of sucks becuse then your IP header is two bytes short
of being aligned. :)
> It appears that Linux developers themselves are convinced that
> buffer chaining is a good idea, since they appear to have plans to
> add it to Linux.
So where's the problem? When these are added, the fragmented datagram
reassembly code can be fixed to take advantage of the new representation.
You seem to be dwelling on transient technical issues.
Optimizing IP datagram reassembly is only a small, insignificant
subtask in comparison to the overall goal of world domination.
> > Also, the only time you will get a lot of fragmented packets is if you are
> > using some brain-dead UDP application that sends large datagrams.
>
> What are you saying? That "smart" applications restrict themselves
> to packets less than 1.5K in size, in order to be optimal for
> Ethernet?
Smart applications will have a tunable packet size, perhaps on a per-network
basis. Indeed, it doesn't make sense to send 1.5K packets if you could send the
same information using larger ones without fragmentation. Or maybe even with
fragmentation. But if your network can handle large datagrams, it is also
likely that fragmentation isn't a concern. IPv4 datagrams are limited to 64 K
in size, so if your network handles packets of that size or larger, you just
aren't going to see fragmentation, so it won't matter one bit how well
optimized the code is for doing reassembly.
> The performance loss on fast networks that support large
> packets is going to be enormous. You wouldn't apply the adjective
> `brain-dead' to an appliaction that can't push fast Ethernet beyond
> 60% capacity, or Gigabit Ethernet beyond 10% capacity?
That depends; some applications simply can never take advantage of the full
capacity of a network because of the kind of protocol they use (for example
stop-go client/server type protocols which tend to be limited by latency rather
than bandwidth). Applications that implement their own protocols over a
datagram service should be tunable so that the system implementors can adjust
the performance to suit a particular deployment situation.
> > The defragmentation only takes place if the packets are destined for the local
> > machine.
>
> Indeed. But those fragmented packets are going to be destined for
> some machine, and reassembled there. Are you saying that one should
> use Linux for routers, but not for end systems?
I am, but nobody seems to be listening. Damn that Linux trash for being so
popular despite not being optimized in every respect!