On Fri, 18 Jun 2010, Oliver Neukum wrote: > We were talking about an implementation of batching network > packets for transfer used by NCM and possibly other drivers. Thus > the requirements of NCM at least have to be met. > > Looking at chapter 3.1 of the NCM specification, it seems > to me that > > a) the host must transfer all data associated with an NTH without > short packets or ZLPs until the end > b) after each short packet or ZLP a new NTH must be sent > > In addition if you look at chapter 3.3.4 of the NCM specification > it is clear that the host must meet fairly arbitrary alignment requirements, > which the device specifies at runtime. I haven't read the NCM spec, so I'll take your word for it. > Now we are within the spec if we send out our data with an NTH, > and NDH and a properly aligned datagramm. However some devices > are likely to be optimized for the host not doing that. > > I was thinking about how we could do batching on the host side. By "batching", you mean sending multiple datagrams with a single NTH and NDH? > 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. > > The problem here, as David pointed out, is that we must copy > each datagramm. 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. Whether this is possible is unknown, because > the alignment is specified at runtime. If you're trying to send multiple datagrams, don't you then have to handle multiple skbs? > In addition I was thinking about doing a single transfer with multiple > URBs the way we do it for storage. That however, as we may not send > short packets is possible only if we give each URB a buffer that is > a multiple of the device's maximum packet size. And I wondered > whether we can meet this requirement without a copy. > > What do you think? Generally speaking, things that fit into a single USB packet must be contiguous. Assuming that the total size of an NTH plus and NDH plus padding is less than 512 (this is high-speed, right?), then either: The NTH, NDH, and padding must fit into the beginning of the skb, or The first part of the skb data must be copied into a separate buffer containing the NTH, NDH, and padding. If you want to transmit multiple datagrams without using any short packets, then most likely you'll have to set up buffers containing a copy of the end of one datagram together with the beginning of the next. Alan Stern -- 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
