Re: driver packet coalesce

On 5/31/07, Andre Oppermann <andre@xxxxxxxxxxx> wrote:
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@xxxxxxxxxxx mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"
>
> 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.

From email I've seen it appears Linux is working thru this issue as well,
and I agree that it makes sense to have one implementation, so lets
get going on it :)

Jack
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: driver packet coalesce
    ... I guess it would only be able to coalesce TCP packets that are adjacent in the same session. ... are a number of obvious and non-obvious interaction issues with LRO ... The LRO implementation (in the driver) has to be aware of all these ... issues and how the TCP stack treats them. ...
    (freebsd-net)
  • Re: driver packet coalesce
    ... And if a driver were to coalesce ... combining packets before sending to the stack, ...
    (freebsd-net)
  • Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
    ... packets but does not modify ETH protocol ... packets used anymore. ... cases where the driver uses multiple lro_mgrs for different receive queues. ... LRO, written up in the Documentation subdirectory. ...
    (Linux-Kernel)
  • Re: [PATCH 1/1] lro: Generic Large Receive Offload for TCP traffic
    ... This patch provides generic Large Receive Offload (LRO) functionality ... i.e. have all packets moved into network layer pass ... The driver seems to be the right place: ... SKBs and does generate SKBs only in the end (see Andrew Gallatins ...
    (Linux-Kernel)
  • Re: driver packet coalesce
    ... And if a driver were to coalesce ... able to coalesce TCP packets that are adjacent in the same session. ...
    (freebsd-net)