Jeff Garzik wrote:
>
> 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 :)
Yep. That would be me. Back when I wrote that section of code, I was pretty
much confused about everything. :)
> 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
Well, there's two limits I can run up against: the boards LAN Tx queue depth
(128), and the driver's request frame queue depth (defaults to 256). When the
board is being used for lan only, I'll always hit the Tx queue depth first, and
I check for that, but there's two scenarios where I might be refused a request
message frame: 1) The scsih host driver module is also loaded and in use (the
board in question is a Fibre Channel board that supports concurent FCP/scsi and
lan traffic) and has eaten up < 128 message frames or 2) we're in the middle
of a diagnostic/hard reset and the message queues are stopped. In either of the
latter two cases, the hard_start_xmit function won't know until it tries to get
a message frame. So, I guess I'll be doing what you suggest below, which is
actually what I'm doing now, minus the brain-dead call to dev_kfree_skb.
> 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.
Thanks.
--
Noah Romer
Driver Developer, CM gopher and Linux Whipping Boy
Storage Components Firmware
LSI Logic Corp.
|