> The code is already a bit factorized. Factorizing it more > so that the gadget and device can use shared encoding and decoding would be good. Yes, I look forward to such patches. :) >From a somewhat distant perspective (what some groups call the "twenty-thousand foot perspetive", as if you're flying over it but not so distant as fifty-thousand feet, etc))... I agree there should not be two separate implementations of NCM on either host or peripheral sides ... and that it'd be nice if vore code could be shared between host and peripheral sides. 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); - 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 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.) - Dave -- 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
