RFC: Fixing USB ethernet for FreeBSD 7.0.

[Ian Dowse]

In message <20061201191731.GR38808 at elvis.mu.org>, Alfred Perlstein writes:
>I recently had the displeasure of trying to use an USB etherdongle
>under FreeBSD.  Result: panic when the interface was started.
>
>I fixed it using a stopgap:
>
>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/if_aue.c?rev=1.101&conte
>nt-type=text/x-cvsweb-markup
>
>There are still some major issues:
>1) requires Giant.
>2) several error paths will still panic the kernel.
>
>I would like to fix them, however that does not seem easy given the
>existing infrastructure.

FYI, some USB ethernet drivers are better than others in this respect
- for example, axe(4) uses sx locks and task queues to avoid the
worst of the issues. The problems remaining in axe are that the
error recovery code in axe_encap should use a task queue, and there
are some cases where if_ioctl routines are called with other locks
held.

On the issue of calling if_ioctl while holding locks, I think this
can happen when if_addmulti() holds locks and calls if_ioctl to
synchronise the hardware with the software state from ifp->if_multiaddrs.
Almost all other if_ioctl calls occur in a context where blocking
is allowed, so it may be possible to rework the if_addmulti() code
paths so that the outer ioctl() code could first update the software
state, release locks and then perform the if_ioctl to synchronise
the hardware state.

>Statement #2:
>Using callbacks to do all IO during an interrupt is programatically
>complex and painful.  For instance, take the case of the following
>code pulled from aue_stop() (which can be called from interrupt
>context):

Note though that most USB ethernet devices require just a single
USB transfer per packet, so it's typically only during error recovery
and setup that asynchronous I/O is too tricky. That's probably easy
enough to fix with a queued task, and since error recovery is rare
it doesn't matter too much if many devices share a task queue.

If there are devices requiring multiple commands to be sent during
normal sending/receiving of packets then you'd probably also want
a separate thread for the TX and RX paths if you were to do the
commands synchronously.

Ian