Am Freitag, 18. Juni 2010 22:34:28 schrieb David Brownell: > > --- On Fri, 6/18/10, Oliver Neukum <oliver@xxxxxxxxxx> wrote: > > > > > Am Donnerstag, 17. Juni 2010 05:41:24 schrieb > > David Brownell: > Not recently, except in the loose sense that > if there's going to be such batching code > for NCM, it ought to be reusable. OK, so we need to discuss 1) do we want batching 2) if so, how do we do it 3) how do we make it reusable Right? > If you wanted to change the topic, it would > really have helped to change $SUBJECT. For > example "how to implement NCM style batching". I am sorry. > However, I think of the issue in a slightly > different way: namely, that what the batching > requires drivers to construct USB transfers OK > (1.N full size packets then a short one to > terminate) out of multiple SKBs (and for the > sake of argument, I'll assume the various NCM > headers are packaged in SKBs too ... possibly > discrete, possibly prepended to other SKBs. Yes. > We don't currently have a way to describe USB > transfers except as the single buffer associated > with an URB. Specifically, we can't build one > transfer out of two or more URBs. We can if the buffers of all but the last URB meet a size criterium. > > It seems to me that we can trivially meet the requirements > > of the > > NCM specification by allocating a large buffer and copying > > the datagramms > > (most likely ethernet frames) with the proper alignment > > into > > the buffer and transfer it by means of one URB. > > > > Right NOW for TX, isn't that the only solution? Pretty much. But we may be able to innovate. > ... Unless you do like the RNDIS code and stick > to one network packet per batch, which lets you > use much smaller buffers (TX only). and > thus avoid a lot of data copies for TX. > > And for RX ... isn't the solution the converse, > but sharing the same packet buffer between all > the single-packet SKBs extracted from that > huge URB transfer buffer? I think so. But it seems to me that for RX the situation is worse. For TX we might use scatter/gather. For RX that is not possible, as we cannot predict where the datagramms will start or stop. > > The problem here, as David pointed out, is that we must > > copy > > each datagramm. > > Copy on TX. You'll observe that for example > the RNDIS RX code shares the underlying packet > buffer (big) between the various packets which > get extracted; ... to avoid copying, but at a > cost in terms of memory fragmentation... Do you have an alternative? > There's a pragmatic issue with that: allocating > big SKBs fragments the relevant memory pools, and > isn't even guaranteed to work. > > THat's another reason to prefer solutions that > stick to queuing single network packets in the > USB transfer queues. Why? I can't see the reason for TX. We could always fall back to smaller buffers, couldn't we? > Thus I thought about what we can do to > > avoid > > a copy. We can avoid a copy if and only if we can fit the > > NTH, > > NDH and padding for alignment into the buffer associated > > with > > the skb we are given. > > That can be assured given MTU tricks; upper > layers of the network stack can be made to > pre-allocate that memory, at least for TX paths. How does that work? > for RX it's less certain, unless the other end > can be made to adopt the same "only one packet > per bundle" policy. Probably it can. The question is how hard that would affect performance. > The trivial case is "one packet per bundle". It's > only larger bundles that get complicated and slow. Do they? I mean they obviously complicatre stuff on the host side, but is that outweighed by gains on the device side? 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
