Messages in this thread | | | Subject | Re: [PATCH 0/2] fix kernel crash with macvtap on top of LRO | From | Ben Hutchings <> | Date | Wed, 12 Jun 2013 15:56:36 +0100 |
| |
On Mon, 2013-06-10 at 10:07 +0300, Michael S. Tsirkin wrote: > On Thu, Feb 07, 2013 at 01:14:20PM -0500, David Miller wrote: > > From: Ben Hutchings <bhutchings@solarflare.com> > > Date: Thu, 7 Feb 2013 16:20:46 +0000 > > > > > If the consensus is still that we must preserve packets exactly (aside > > > from the usual modifications by IP routers) then LRO should be disabled > > > on all devices for which forwarding is enabled. > > > > I believe this is still undoubtedly the consensus. > > With virtio we are getting packets from a linux host, > so we could thinkably preserve packets exactly > even with LRO. I am guessing other hardware could be > doing this as well. > > I am not sure what information would need to be preserved - > could someone help clarify please?
Some LRO implementations may not preserve:
- Packet boundaries - TSO/GSO produces packets all the same size, except possibly for the last one. GRO therefore flushes a flow after merging a packet with a different segment size. - IPv4 TTL, IPv6 hop-limit, TCP timestamp - TSO/GSO will put the same values in all packets. GRO flushes a flow if they change. - IPv4 fragment ID - TSO/GSO produces consecutive fragment IDs. GRO flushes a flow if it sees a non-consecutive fragment ID. - MAC header, IPv4 TOS, IPv6 traffic class - Should be the same for all packets in a flow. GRO actually checks and flushes a flow if they change.
Ben.
-- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked.
| |