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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
