Hi Or Gerlitz <[EMAIL PROTECTED]> 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
_______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
