<br><tt><font size=2>Hi</font></tt>
<br>
<br><tt><font size=2>Or Gerlitz <ogerlitz@voltaire.com> wrote on
25.06.2008 11:26:12:<br>
<br>
> Jan-Bernd,<br>
> <br>
> I understand from your response that lro_mgr->ip_summed is not
needed, <br>
> so I guess it should removed from all other places that (eg its <br>
> definition and usage in inet_lro.[ch] and under drivers/net.<br>
> </font></tt>
<br>
<br><tt><font size=2>no, what I meant is that it is only not needed at
that particular place as </font></tt>
<br><tt><font size=2>the packet is not handled by LRO. Without this line
the driver can set an individual </font></tt>
<br><tt><font size=2>value for each SKB that is not aggregated if wished.
For example when the packet is not a valid IP packet.</font></tt>
<br><tt><font size=2>However, removing all ip_summed fields impacts the
fragment lro mode. There we have to set</font></tt>
<br><tt><font size=2>some value for not aggregated packets. The SKBs are
generated within the LRO engine.</font></tt>
<br><tt><font size=2>If desired (and if there is HW that wants to use that)
</font></tt>
<br><tt><font size=2>we can pass that value for each provided fragment.
This would add one additional paramter to the already 8 parameters</font></tt>
<br><tt><font size=2>of __lro_proc_segment. That is of course possible.</font></tt>
<br>
<br><tt><font size=2><br>
> Second, if lro_mgr->aggr_ip_summed is indeed needed, I tend to
think it <br>
> need to be derived per received packet from skb->ip_summed, since
the <br>
> kernel allows for drivers ti have different checksum offload <br>
> capabilities which for some drivers might be impossible to be encoded
in <br>
> one global value (lro_mgr->aggr_ip_summed), what's your thinking
here?</font></tt>
<br>
<br><tt><font size=2>I think that for valid TCP/IP packets this value should
always be the same</font></tt>
<br><tt><font size=2>as the hardware either support the set ip_summed_aggr
value for TCP/IPv4 packets, or not.</font></tt>
<br><tt><font size=2>Maybe that assumption is not right, but so far I haven't
seen any hardware that behaves</font></tt>
<br><tt><font size=2>in a different way.</font></tt>
<br><tt><font size=2><br>
> <br>
> Third, consider a case where the receiver gets some very small data
<br>
> chunks (eg file/block target that has to serve lots of IOPS for some
<br>
> clients but also large IOs for other clients), that is some senders
set <br>
> TCP_NODELAY, etc. Now, looking in the code _lro_proc_skb() (below)
and <br>
> doing reading some reads at the archives, my understanding is that
its <br>
> very possible that a large set of small packets would be gathered
and <br>
> sent up to the stack only by the consumer calling lro_flush_all in
the <br>
> end of its NAPI poll loop. Am I correct?</font></tt>
<br>
<br><tt><font size=2>yes, that is possible. An increased delay is the prise
of LRO :-)</font></tt>
<br><tt><font size=2><br>
Regards,</font></tt>
<br><tt><font size=2>Jan-Bernd<br>
</font></tt>