On Wednesday 23 February 2005 9:26 am, Alex Sanks wrote: > Hi Dave et al, > > I've been supporting a customer here who is looking to use g_ether to > support CDC Ethernet and RNDIS. We noticed that there seems to be a severe > bottleneck when talking to an RNDIS host (~5MB/sec FTPs thru a WinXP RNDIS > host versus ~18MB/sec when talking thru a Linux CDC host...both measured on > my PC with a NET2280). I took a trace with a USB analyzer and the NET2280's > NAKing, so it seems the bottleneck's on the device side.
Where/when is it NAKing? That shouldn't happen much if at all; you might try changing the queue length, but as a rule I've found the queues don't usually stay empty for long. Are you seeing any errors be reported on that link? > I seem to recall hearing talk of effiency problems in the RNDIS device code. > Is this correct? If so, could someone pass along some info on where the > problem(s) lie? I don't remember hearing anyone talk about such things (except maybe on the MS-Windows side!), but I did happen to notice one issue not long ago. Specifically, on the RX side (OUT to device), every packet gets needlessly copied to remove the RNDIS packet header. There was also a patch posted not that long ago to tweak the alignment of packets so that the IP headers are aligned at 4 byte boundaries. That's not supposed to matter except for (in this context minor) dcache effects, and it certainly wouldn't account for what you observed. But I mention it because that's how I noticed that needless copy: copying just happens to preserve that alignment tweak. > I'm not fluent in CDC or RNDIS, so if there's an > architectural problem I don't think I could devote enough time to be useful, > but if there's just some busywork that nobody's wanted to do I may be able > to help out... I'm glad you asked ... :) The way to get rid of that packet copy is to make rndis_rm_header() take the whole SKB as a parameter, and use skb_pull instead. It'd be handy to know how big those RNDIS headers end up being ... specifically, if you see any that aren't multiples of four bytes, that'd be interesting. I don't think this would win you 13 MByte/sec of throughput, but it will make some kind of difference. Especially on more typical embedded system CPUs, which don't have CPU cycles to spare! - Dave > > Regards, > Alex > > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
