driver packet coalesce

[Andre Oppermann]

Julian Elischer wrote:
> Andrew Thompson wrote:
>> On Wed, May 30, 2007 at 04:45:05PM -0700, Jack Vogel wrote:
>>> Does any driver do this now? And if a driver were to coalesce
>>> packets and send something up the stack that violates mss
>>> will it barf?
>>
>> It would barf for things like bridging where the packet gets spit out a
>> different interface. The bridge driver already has code to disable
>> txcsum so it could be made to handle that too.
>>
>>
>> Andrew
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> 
> This is part od TOE right?

No, LRO (Large Receive Offload).

> I presume that it wouldn't coalesce packets that are not destined for 
> the local
> machine?  would it coalesce in promiscuous mode?   I guess it would only 
> be able to coalesce TCP packets that are adjacent in the same session. 
> Whether it also can coalesce adjacent packets that are destined for another
> machine (for which it is not running the session) is not known... I 
> would guess it
> wouldn't do it.

These are all nasty problems that should be handled in one central
place for various protocols (primarily TCP right now).  For TCP there
are a number of obvious and non-obvious interaction issues with LRO
to be handled.  For example LRO may have a drastic effect on stacks
that don't (yet) make use of ABC and increase the CWND by one for
every ACK received.  With LRO up to some 44 segments may be aggregated.
On back to back connections with microsecond RTT this isn't much a
problem.  However once you have even 1ms performance goes way down.
The LRO implementation (in the driver) has to be aware of all these
issues and how the TCP stack treats them.  That's why I want to have
only one LRO implementation in the base system that is used by all
drivers.

-- 
Andre