Although I have not tried this latest patch, the existing e100 and e1000 in
2.4.21 seldom seem to return true to this method: netif_queue_stopped(odev),
even when the next hard_start_xmit() call fails.
Returning an error from hard_start_xmit() from normal ethernet
drivers is, frankly, a driver bug and should never happen.
What's "normal" mean?
One that can manage it's own TX resources.
Which for the moment, would seem to exclude USB.
With the current USB stack, network adapters tend to need
memory allocations there. Those can fail, though it seems
that's not very common. Doesn't seem like a bug, for all
that I'd rather see the those paths be zero-alloc in 2.7.
Any particular reason why the SKB data itself can't be
mapped directly? We created all of these DMA mapping
abstractions remember? :-)
Yes, but the network drivers weren't the ones that needed them!
Some older drivers do copy the buffer out of (or for rx, into)
the skb, but newer ones just pass the skb data, avoiding a copy.
In either case, the buffer was always DMA mapped. Nowadays,
some drivers will even set NETIF_F_HIGHDMA if they're going out
through a host controller that allows it! (Intel boxes only,
Another option is to pre-allocate, such that while the TX
queue is awake we know we have enough resources to send any
given packet. Then in ->hard_start_xmit() after using a buffer
we allocate a replacement buffer, if this fails in such a way
that a subsequent ->hard_start_xmit() could possibly fail, we
Pre-allocation can be done for the URBs that wrap the data
buffers, yes. Not often done today; but it could be.
What can't be pre-allocated in a reliable way is the resources
used by the host controller drivers, specifically the transfer
descriptors. EHCI and OHCI usually need one per URB, unless
MTU is over 4 KB. UHCI normally needs quite a few.
The API that works inside USB "gadgets' does allow pre-allocation
at all those levels, mostly because it's factored to make the
submission and completion paths fast. So that "stop if can't
pre-allocate" scheme would work, given an "ether.c" patch! :)