I'm tracking down some obscure bugs in the mpt fusion network driver and am
wondering about the correct behavior of hard_start_xmit implementations.
Specifically, if the network stack gives you a packet to transmit and you
immediately know you're not going to be able to do so (in my case, when I'm
unable to get a message frame so I can talk with the board, a rare condition),
what's the expected handling of the skb and what does the network stack want to
see as the return value?
The existing behavior of the driver is to call netif_stop_queu, call
dev_kfree_skb, and then return a non-zero value. From the results I'm seeing,
calling dev_kfree_skb isn't a good thing. Should I be placing the skb on an
internal queue and retrying once I've got the resources to do so or just leave
it alone and let the network stack deal with it? I haven't yet found anything
to indicate that the return value of hard_start_xmit is checked for anything
other than 0, does it make any diff what non-zero value is used?
Driver Developer, CM gopher and Linux Whipping Boy
Storage Components Firmware
LSI Logic Corp.