Noah Romer wrote:
> 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?
It sounds like the original author was a bit confused :)
Is it possible to decide whether there is room to transmit more, after
you queue a packet? If so, the hard_start_xmit logic is
...send 1 skb to hardware...
if (no more tx buffers available)
netif_stop_queue
If it is not possible to use this scheme, then the driver's existing
logic simply needs to remove the dev_kfree_skb:
if (no more tx buffers available) {
netif_stop_queue(dev);
return 1;
}
...send 1 skb to hardware...
If your driver supports fragmented skbs, then the latter logic is what
must be used.
--
Jeff Garzik | A recent study has shown that too much soup
Building 1024 | can cause malaise in laboratory mice.
MandrakeSoft |
|