--- On Sun, 6/13/10, Oliver Neukum <oliver@xxxxxxxxxx> wrote: > From: Oliver Neukum <oliver@xxxxxxxxxx> > Subject: Re: [RFC] CDC NCM USB host driver > To: "David Brownell" <david-b@xxxxxxxxxxx> > Cc: "Yauheni Kaliuta" <yauheni.kaliuta@xxxxxxxxx>, "Sjur BRENDELAND" <sjur.brandeland@xxxxxxxxxxxxxx>, "Greg Lee" <glee-list@xxxxxxxxxx>, "linux-usb@xxxxxxxxxxxxxxx" <linux-usb@xxxxxxxxxxxxxxx>, "gregkh@xxxxxxx" <gregkh@xxxxxxx>, "sjurbr@xxxxxxxxx" <sjurbr@xxxxxxxxx>, "Alexey ORISHKO" <alexey.orishko@xxxxxxxxxxxxxx>, "Linus WALLEIJ" <linus.walleij@xxxxxxxxxxxxxx>, "Hans Petter SELASKY" <hans.petter.selasky@xxxxxxxxxxxxxx>, "Balbi Felipe (Nokia-D/Helsinki)" <felipe.balbi@xxxxxxxxx> > Date: Sunday, June 13, 2010, 12:09 AM > Am Samstag, 12. Juni 2010 21:58:35 > > - specific protocol headers, defined in > > the NCM spec (NCM-specific); > > Yes, they should go into a common header file. Agreed; Some <linux/usb/...> header I'd suggest, rather than a <net/...> one, but that could be argued either way. > > - a packet batching mech anism 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. It would require a shared abstraction, that's all ... for example, a method along the lines of a maybe_add_to_batch(packet, batch)) call. > 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 first 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 That "if" doesn't usually hold... :) > fir things like putting headers on it, why not batch it > during > that process? Network stacks, such as the Linux one, are generally engineered so that adding a header is cheap ... and certainly doesn't *require* copying the packet data.In Linux, there's usually extra space pre-allocated at the start of each packet, for adding more headers. There's a difference between a small handful of header field assignments like packet->hdr.fieldX = ... and a memcpy of maybe 2KB of packet data. Packet size distributions are actually bimodal, and the larger size is probably not quite 2K. -- 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
