Am Samstag, 12. Juni 2010 21:58:35 schrieb David Brownell: > But also, one way to look at this is that > NCM drivers combine two things: > > - specific protocol headers, defined in > the NCM spec (NCM-specific); Yes, they should go into a common header file. > - a packet batching mechanism like the ones > used in RNDIS and ECM. (Combining multiple > Ethernet packets into one larger USB transfer.) > > ISTR some other drivers/net/usb code could use > such a mechanism to talk to USB-to-Ethernet > adapter hardware which batches directly.) > > WOuld it be practical to separate those two > things, so that the RNDIS and ECM code (and > maybe those hardware adapters) can > leverage the batching code? (ISTR the Linux host That would require shared constraints for the batching. If you need only batching with a) fixed alignment b) "control blocks" of fixed size c) some kind of linkage after adding a packet to the batch it can be done and is a good idea. If the hardware has exotic constraints on what can be batched we can't do it cleanly. > and peripheral implementations of those know > how to un-batch on the RX side, but none of > them will create batches on their TX paths. > > For what it's worth, although I'll be glad to > see Linux support NCM, if for no other reason > than "better interop standards support") ... > I still persist in believing that the batching > is mostly a way to work around limitations that > have not been an issue on Linux. (We usually > just queue 32 packets of 2KB each, which most > host-side DMA hardware transfers very quickly, > instead of furst memcpying into one 64KB buffer.) > (Worth noting: the memcpy consumes more battery > power than the DMA, on most hardware.) That seems strange. If we have to copy around data at all fir things like putting headers on it, why not batch it during that process? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
