On Sun, 03 Aug 2003 20:09:10 -0700
David Brownell <david-b@xxxxxxxxxxx> wrote:
> David S. Miller wrote:
> >>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:
> >>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.
> 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? :-)
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
Look to tg3 to see what I'm talking about in general.
netif_stop_queue() is done at the moment at which it may be possible
that we cannot accept the queueing of a TX packet. This means that
when TX entries available <= MAX_SKB_FRAGS + 1, we stop the queue.
This guarentees that we will always be able to handle any packet given
to us via ->hard_start_xmit().