netdev - Re: LRO restructuring?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090219135358.GA11319@gondor.apana.org.au>
Date:	Thu, 19 Feb 2009 21:53:58 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	James Huang <jamesclhuang@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: LRO restructuring?

James Huang <jamesclhuang@...il.com> wrote:
> Hi Herbert,

Please cc me if you're going to address the email to me :)

>    Any idea when this LRO restructuring work will be done? 

The target is to get GRO into 2.6.30, and have all LRO drivers
converted by 2.6.31.

> Making LRO available even when ip forwarding is enabled will significantly 
> improve performace of network appliances in the data path.  

I'd like to see more performance data on the forwarding side.
The act of aggregation isn't exactly free so it very much depends
on what you're forwarding.

The driver for all this work is bridging used for virtualisation
where the data is very likely to be mergeable.

> I have some questions on this: 
> (1) Based on the emails in this thread, I suppose you are going to keep the 
> original length of each segment you coalesced into the big packet and use that 
> info to segment the big packet on the output path.  In case the packet was 
> modified by an appliance in the path and the total length is changed (e.g. NAT 
> on ftp control packets), should the corresponding segment length info also get 
> updated?  This same question also applies to the checksums.

If packet length changes due to NAT then we're no loner bound
by the end-to-end restriction so we can do whatever we want.

For GRO we treat it in exactly the same way as a GSO packet that
undergoes NAT.  That is, NAT just sees a very large IP packet and
does what it has to do, and on final output we resegment the packet.

> (2) Do you make sure all of the segments to be coalesced have the same DF bit?

Yes.

> (3) I think bridged packets should not be LROed. Whether a packet is bridged 
> or not can be based on the L2 MAC destination address.  Is this how it is done?

We currently require the Ethernet header to be identical.

> (4) Does LRO work only for IPv4?  Any plan to extend it to support IPv6?

IPv6 is supported.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html