On Mon, 5 Oct 2015, Paul Jones wrote: > I�m investigating the (lack of) performance (around 150MB/s) of the USB3380 gadget in mass storage mode. > Whilst tracing on a Linux 4.1 host I noticed that the Linux max storage driver is requesting 240 blocks, 16 blocks, 240 blocks, 16 blocks, etc. when doing a dd directly on the device: > dd if=/dev/sdb of=/dev/null bs=64k count=8k > where /dev/sdb is the emulated device. > The emulated device is provided from a secondary machine with a USB3380 card emulating the mass storage device from a local SSD (local dd of the disk file reads at 542 MB/s). > > lsusb on the host: > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M > |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M > |__ Port 6: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M > > lspci on the host: ... > Tracing using usbmon on the host shows: > ffff88002ea45b40 558636438 S Bo:2:003:2 -115 31 = 55534243 63c20000 00000000 00000600 00000000 00000000 00000000 000000 > ffff88002ea45b40 558636455 C Bo:2:003:2 0 31 > > ffff88002ea45b40 558636459 S Bi:2:003:1 -115 13 < > ffff88002ea45b40 558636537 C Bi:2:003:1 0 13 = 55534253 63c20000 00000000 00 > ffff88002ea45b40 558636593 S Bo:2:003:2 -115 31 = 55534243 64c20000 00000000 0000061e 00000001 00000000 00000000 000000 > ffff88002ea45b40 558636610 C Bo:2:003:2 0 31 > > ffff88002ea45b40 558636627 S Bi:2:003:1 -115 13 < > ffff88002ea45b40 558636669 C Bi:2:003:1 0 13 = 55534253 64c20000 00000000 00 > ffff88002ea45b40 558636748 S Bo:2:003:2 -115 31 = 55534243 65c20000 00e00100 80000a28 00000000 000000f0 00000000 000000 > ffff88002ea45b40 558636757 C Bo:2:003:2 0 31 > > ffff880407982f00 558636765 S Bi:2:003:1 -115 122880 < > ffff880407982f00 558637699 C Bi:2:003:1 0 122880 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > ffff88002ea45b40 558637717 S Bi:2:003:1 -115 13 < > ffff88002ea45b40 558637728 C Bi:2:003:1 0 13 = 55534253 65c20000 00000000 00 > ffff88002ea45b40 558637760 S Bo:2:003:2 -115 31 = 55534243 66c20000 00200000 80000a28 00000000 f0000010 00000000 000000 > ffff88002ea45b40 558637778 C Bo:2:003:2 0 31 > > ffff88040ca76a80 558637797 S Bi:2:003:1 -115 8192 < > ffff88040ca76a80 558637892 C Bi:2:003:1 0 8192 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > ffff88002ea45b40 558637908 S Bi:2:003:1 -115 13 < > ffff88002ea45b40 558637933 C Bi:2:003:1 0 13 = 55534253 66c20000 00000000 00 > ffff88002ea45b40 558637959 S Bo:2:003:2 -115 31 = 55534243 67c20000 00e00100 80000a28 00000001 000000f0 00000000 000000 > ffff88002ea45b40 558637973 C Bo:2:003:2 0 31 > > ffff880407982f00 558637976 S Bi:2:003:1 -115 122880 < > ffff880407982f00 558638898 C Bi:2:003:1 0 122880 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > ffff88002ea45b40 558638901 S Bi:2:003:1 -115 13 < > ffff88002ea45b40 558638938 C Bi:2:003:1 0 13 = 55534253 67c20000 00000000 00 > ffff88002ea45b40 558638976 S Bo:2:003:2 -115 31 = 55534243 68c20000 00200000 80000a28 00000001 f0000010 00000000 000000 > ffff88002ea45b40 558638984 C Bo:2:003:2 0 31 > > ffff88040ca76a80 558638992 S Bi:2:003:1 -115 8192 < > ffff88040ca76a80 558639095 C Bi:2:003:1 0 8192 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > ffff88002ea45b40 558639110 S Bi:2:003:1 -115 13 < > ffff88002ea45b40 558639136 C Bi:2:003:1 0 13 = 55534253 68c20000 00000000 00 > > Any ideas why the driver is requesting varying block sizes? The usb-storage driver requests what the block layer tells it to request. Unless you change the settings, the maximum number of blocks allowed in a single transfer is 240 (i.e., 120 KB). Consequently, 128-KB reads get broken up into 120 KB followed by 8 KB. (You can alter the default by writing to /sys/block/sd*/queue/max_sectors_kb -- fill in the * appropriately). > It also seems odd that the mass storage gadget takes a long time to > respond to the CBW of each read request (as it doesn�t actually need > to return the data at that point). I don't know what you mean. The response time for the first READ CBW was 9 microseconds (558636757 - 558636748 in the timestamp column); for the second it was 18 us; then 14 us and 8 us for the third and fourth. Those don't seem very long. Are you sure you're not looking at the time required to transfer the actual data? > It seems that the gadget is waiting for the underlying request to > retrieve data blocks to actually finish, before acknowledging the > request, as the response time after a 240 block request is > consistently much longer than the response time after a 16 block > request. No, the gadget definitely responds to the CBW before reading any data. Besides, the response times for the first and second READs above contradict your observation: 9 us for 240 blocks, then 18 us for 16 blocks. > Wouldn�t it be more efficient to immediately acknowledge the > request, kick off the underlying request to retrieve the data blocks > in the gadget and use flow control in the following BULK IN request > if the data hasn�t arrived yet or is arriving slower than the USB > line speed? That's exactly what the gadget _does_ do. > Or is there some parameter that I have overlooked that > controls/influences this behaviour? No; it always works this way. 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
