David Laight <David.Laight@xxxxxxxxxx> writes: > Since USB bulk data are terminated by a short fragment there is actually > no need for the URB be long enough for the full message. Provided the > URB are multiples of the USB message size (1k for USB 3) the message > can be received into multiple URB - the driver just has to be willing > to merge URB buffers (as well as split them) when generating the ethernet > frames. > > What the driver needs to do us allocate URB with 2k (or 4k) buffers and > only allocate the skb when processing the receive data. > Unfortunately this is a major rework of usb_net.c Yes, I believe this is the way to go as well. I have been thinking about it in the context of the cdc_ncm driver. One problem with the NCM protocol is that it will have to merge all the buffers of a "NCM Transfer Block" (NTB) before it can process any part of it. The protocol puts no restrictions on the internal pointers in a NTB, so there is no guarantee that we can start at the beginning and work our way towards the end of it. The contained packets can be interleaved with index(es) or the index can be at the end etc. But this should still be possible to parse using a list of shorter buffers to hold each NTB. > Note that some of the usb ethernet drivers allocate large skb then > lie about the truesize. Hmm, which drivers are these? Bjørn -- 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
