Messages in this thread | | | Date | Tue, 3 Feb 2009 14:49:44 +0300 | From | Evgeniy Polyakov <> | Subject | Re: [PATCH v2] tcp: splice as many packets as possible at once |
| |
On Tue, Feb 03, 2009 at 10:24:31PM +1100, Herbert Xu (herbert@gondor.apana.org.au) wrote: > > I even believe that for some hardware it is the only way to deal > > with the jumbo frames. > > Not necessarily. Even if the hardware can only DMA into contiguous > memory, we can always allocate a sufficient number of contiguous > buffers initially, and then always copy them into fragmented skbs > at receive time. This way the contiguous buffers are never > depleted.
How many such preallocated frames is enough? Does it enough to have all sockets recv buffer sizes divided by the MTU size? Or just some of them, or... That will work but there are way too many corner cases.
> Granted copying sucks, but this is really because the underlying > hardware is badly designed. Also copying is way better than > not receiving at all due to memory fragmentation.
Maybe just do not allow jumbo frames when memory is fragmented enough and fallback to the smaller MTU in this case? With LRO/GRO stuff there should be not that much of the overhead compared to multiple-page copies.
-- Evgeniy Polyakov
| |