From: Bjørn Mork > Hello Oliver & other clueful gurus! > > I started looking at how to improve the OOM handling in usbnet, but have > to admit that this is way over my head. I don't think I dare touching > it... > > I've seen a few reports clearly showing that we do have a problem. One > example is here: http://forums.whirlpool.net.au/forum-replies.cfm?t=2207038&p=57#r1122 > > Although all the reports I've seen are from users of cdc_ncm, I don't > think this problem is specific to any particualar minidriver. But it is > of course easier to trigger it using a minidriver with (too?) large > buffers, like the cdc_ncm minidriver family. > > To recall: The NCM and MBIM protocols aggregate packets before > transission over the USB link, requiring USB buffers with multiple > ethernet/IP packets. Common code used by both cdc_mbim and cdc_ncm > currently cap the buffers at 32768 bytes (hard coded limit), which is > still too high for some embedded hosts. This results in failures to > allocate buffers in rx_submit (flags == GFP_ATOMIC when it is called > from the URB callback): I think that some of these drivers need to use a slightly different buffer scheme to the one that usbnet currently supports. In many cases the usb hardware will aggregate many receive frames into a single USB bulk packet, and also supports the driver aggregating multiple transmit frames. Not all the stub drivers aggregate transmit packets. It really doesn't make much sense (to me) to transmit and receive aggregated packets from dynamically allocated skb. I'd have thought it much better to copy the ethernet frames to/from pre-allocated buffers. Yes, you take the cost of a data copy, but for USB2 the data rate isn't that high, and USB3 ought to be able to do scatter-gather transmit (when xhci is fixed). The transmit side could have 2 buffers, and at most one active urb. So merges until the previous tx finishes (or 3 buffers and two active tx). The rx side needs a few buffers that are multiples of the usb transfer size - so that long usb bulk data packets can end up in multiple urb, and then get merged into a single skb correctly sized for the ethernet frame. For USB2 maybe you could use 1536 byte skb - but I expect that you still want to copy short frames. At the moment some driver allocate very large rx skb - and then lie about their truesize. If any devices actually do receive segment offload (the ax88179 does TSO, don't know about the rx side), then using large skb for the rx side just in case they are very long packets when they can be passed directly up the stack. David ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
