RE: [PATCH net-next] r8152: reduce memory copy for rx
Eric Dumazet [mailto:eric.duma...@gmail.com] Sent: Wednesday, December 03, 2014 3:15 PM [...] Have you tried using more concurrent RX flows, in a possibly lossy environment (so that TCP is forced to queue packets in out of order queue) ? I don't do the test. I would check it next time. skb cloning prevents GRO and TCP coalescing from working. netfilter might also be forced to copy whole frame in case a mangle is needed (eg with NAT ...) I would rather try to implement GRO, and/or using fragments instead of pure linear skbs. (skb-head would be around 128 or 256 bytes, and you attach to skb the frame as a page fragment) Thanks for your response. I would study the GRO first. Best Regards, Hayes -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] r8152: reduce memory copy for rx
On Wed, 2014-12-03 at 13:14 +0800, Hayes Wang wrote: If the data size is more than half of the AGG_BUG_SZ, allocate a new rx buffer and use skb_clone() to avoid the memory copy. The original method is that allocate the memory and copy data for each packet in a rx buffer. The new one is that when the data size for a rx buffer is more than RX_THRESHOLD_CLONED, allocate a new rx buffer and use skb_clone for each packet in the rx buffer. According to the experiment, the new mothod has better performance. Better performance for what workload exactly ? cloning in rx path has many drawbacks, with skb-truesize being usually wrong. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH net-next] r8152: reduce memory copy for rx
Eric Dumazet [mailto:eric.duma...@gmail.com] Sent: Wednesday, December 03, 2014 2:08 PM [...] Better performance for what workload exactly ? I test it by using Chariot with 4 Tx and 4 Rx. It has about 4% improvement. cloning in rx path has many drawbacks, with skb-truesize being usually wrong. Excuse me. I find the skb_clone() would copy the truesize from original skb. Do you mean the value may not be suitable for the cloned skb? Could other method do the same thing? Or, do you think keeping the original one is better? Best Regards, Hayes -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] r8152: reduce memory copy for rx
On Wed, 2014-12-03 at 07:05 +, Hayes Wang wrote: Eric Dumazet [mailto:eric.duma...@gmail.com] Sent: Wednesday, December 03, 2014 2:08 PM [...] Better performance for what workload exactly ? I test it by using Chariot with 4 Tx and 4 Rx. It has about 4% improvement. Have you tried using more concurrent RX flows, in a possibly lossy environment (so that TCP is forced to queue packets in out of order queue) ? cloning in rx path has many drawbacks, with skb-truesize being usually wrong. Excuse me. I find the skb_clone() would copy the truesize from original skb. Do you mean the value may not be suitable for the cloned skb? With cloning, (skb-len / skb-truesize) will eventually be very very small, forcing TCP stack to perform collapses (copies !!!) under pressure. Could other method do the same thing? Or, do you think keeping the original one is better? skb cloning prevents GRO and TCP coalescing from working. netfilter might also be forced to copy whole frame in case a mangle is needed (eg with NAT ...) I would rather try to implement GRO, and/or using fragments instead of pure linear skbs. (skb-head would be around 128 or 256 bytes, and you attach to skb the frame as a page fragment) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
