netdev - Re: [ofa-general] [PATCH] net/inet_lro: remove setting skb->ip

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-next>] [day] [month] [year] [list]

Message-ID: <4862304D.2050306@voltaire.com>
Date:	Wed, 25 Jun 2008 14:47:25 +0300
From:	Or Gerlitz <ogerlitz@...taire.com>
To:	Jan-Bernd Themann <THEMANN@...ibm.com>,
	Eli Cohen <eli@....mellanox.co.il>
CC:	OpenFabrics General <general@...ts.openfabrics.org>,
	netdev@...r.kernel.org, Roland Dreier <rdreier@...co.com>,
	Vladimir Sokolovsky <vlad@...lanox.co.il>
Subject: Re: [ofa-general] [PATCH] net/inet_lro: remove setting skb->ip_summed
 when not LRO-able

Jan-Bernd Themann wrote:
> no, what I meant is that it is only not needed at that particular 
> place as  the packet is not handled by LRO. Without this line the 
> driver can set an individual  value for each SKB that is not 
> aggregated if wished. For example when the packet is not a valid IP 
> packet.  However, removing all ip_summed fields impacts the fragment 
> lro mode. There we have to set some value for not aggregated packets. 
> The SKBs are generated within the LRO engine. If desired (and if there 
> is HW that wants to use that) we can pass that value for each provided 
> fragment. This would add one additional paramter to the already 8 
> parameters of __lro_proc_segment. That is of course possible.
OK, understood, both points. 

Eli, lets add to this patch a comment in inet_lro.h saying that the 
value of lro_mgr->ip_summed is ignored by the core lro code for drivers 
that use the non fragmented mode. Also for the ipoib patch, lets not set 
this value.

> I think that for valid TCP/IP packets this value should always be the 
> same as the hardware either support the set ip_summed_aggr value for 
> TCP/IPv4 packets, or not. Maybe that assumption is not right, but so 
> far I haven't seen any hardware that behaves in a different way.
Yes, for TCP/IPv4 you seem to be right and here the problem was in the 
lro patch to ipoib which set this value blindly regardless of the HW 
capabilities, I asked Vlad to change this in the next version of the 
patch. As for other types of traffic, I was thinking that allowing the 
driver to set it per packet makes a better isolation between the core 
lro code to the driver, but this is not major issue.
> yes, that is possible. An increased delay is the prise of LRO :-)
>
Is there some pointer you might be able to provide on LRO benchmark for 
small packets and/or mixed small/large packet streams?

Or.


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