<br><tt><font size=2>Or Gerlitz <ogerlitz@voltaire.com> wrote on
25.06.2008 13:47:25:<br>
<br>
> Jan-Bernd Themann wrote:<br>
> > no, what I meant is that it is only not needed at that particular
<br>
> > place as  the packet is not handled by LRO. Without this
line the <br>
> > driver can set an individual  value for each SKB that is
not <br>
> > aggregated if wished. For example when the packet is not a valid
IP <br>
> > packet.  However, removing all ip_summed fields impacts
the fragment <br>
> > lro mode. There we have to set some value for not aggregated
packets. <br>
> > The SKBs are generated within the LRO engine. If desired (and
if there <br>
> > is HW that wants to use that) we can pass that value for each
provided <br>
> > fragment. This would add one additional paramter to the already
8 <br>
> > parameters of __lro_proc_segment. That is of course possible.<br>
> OK, understood, both points. <br>
> <br>
> Eli, lets add to this patch a comment in inet_lro.h saying that the
<br>
> value of lro_mgr->ip_summed is ignored by the core lro code for
drivers <br>
> that use the non fragmented mode. Also for the ipoib patch, lets not
set <br>
> this value.<br>
> <br>
> > I think that for valid TCP/IP packets this value should always
be the <br>
> > same as the hardware either support the set ip_summed_aggr value
for <br>
> > TCP/IPv4 packets, or not. Maybe that assumption is not right,
but so <br>
> > far I haven't seen any hardware that behaves in a different way.<br>
> Yes, for TCP/IPv4 you seem to be right and here the problem was in
the <br>
> lro patch to ipoib which set this value blindly regardless of the
HW <br>
> capabilities, I asked Vlad to change this in the next version of the
<br>
> patch. As for other types of traffic, I was thinking that allowing
the <br>
> driver to set it per packet makes a better isolation between the core
<br>
> lro code to the driver, but this is not major issue.<br>
> > yes, that is possible. An increased delay is the prise of LRO
:-)<br>
> ><br>
> Is there some pointer you might be able to provide on LRO benchmark
for <br>
> small packets and/or mixed small/large packet streams?</font></tt>
<br>
<br>
<br><tt><font size=2><br>
> <br>
> Or.<br>
> <br>
> <br>
</font></tt>