Re: usbnet OOM handling - possible CPU starvation?

[Oliver Neukum <oneukum@suse.de>]

On Tue, 2014-03-18 at 10:29 +0000, David Laight wrote:
> From: Bjørn Mork

Hi,

> > 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):

True. We cannot rely on this working from a callback. So the correct
OOM response would happen from a delayed work queue.

> 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.

That makes sense.

> 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).

We had bad experiences with that scheme. It turns out that you
need to have two URBs in flight, because the time you lose waiting
for the next frame to begin is too high.
So you need at least three buffers. 

	Regards
		Oliver