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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 18 Feb 2009 19:25:49 +0000 (UTC)
From:	James Huang <jamesclhuang@...il.com>
To:	netdev@...r.kernel.org
Subject:  Re: LRO restructuring?

Hi Herbert,

    Any idea when this LRO restructuring work will be done? 
Making LRO available even when ip forwarding is enabled will significantly 
improve performace of network appliances in the data path.  

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.

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

(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?

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

Thanks,
James Huang

--
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