[ofa-general] [PATCH] net/inet_lro: remove setting skb->ip_summed when not LRO-able

[Jan-Bernd Themann]

Hi

Or Gerlitz <ogerlitz at voltaire.com> wrote on 25.06.2008 11:26:12:

> Jan-Bernd,
> 
> I understand from your response that lro_mgr->ip_summed is not needed, 
> so I guess it should removed from all other places that (eg its 
> definition and usage in inet_lro.[ch] and under drivers/net.
> 

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.


> Second, if lro_mgr->aggr_ip_summed is indeed needed, I tend to think it 
> need to be derived per received packet from skb->ip_summed, since the 
> kernel allows for drivers ti have different checksum offload 
> capabilities which for some drivers might be impossible to be encoded in 

> one global value (lro_mgr->aggr_ip_summed), what's your thinking here?

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.

> 
> Third, consider a case where the receiver gets some very small data 
> chunks (eg file/block target that has to serve lots of IOPS for some 
> clients but also large IOs for other clients), that is some senders set 
> TCP_NODELAY, etc. Now, looking in the code _lro_proc_skb() (below) and 
> doing reading some reads at the archives, my understanding is that its 
> very possible that a large set of small packets would be gathered and 
> sent up to the stack only by the consumer calling lro_flush_all in the 
> end of its NAPI poll loop. Am I correct?

yes, that is possible. An increased delay is the prise of LRO :-)

Regards,
Jan-Bernd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20080625/c343a4ed/attachment.html>