Linux-kernel mailing list archive 1997-48,: Re: net device tx handler (hard_start_xmit) return code ?

# Re: net device tx handler (hard_start_xmit) return code ?

Donald Becker (becker@cesdis1.gsfc.nasa.gov)
Fri, 5 Dec 1997 12:21:12 -0500 (EST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Shaw Carruthers: "Sound in 2.1.71"
- Previous message: Miquel van Smoorenburg: "Re: 2.1.71 failes to believe my VGA is usable as console"
- In reply to: Michael Tross: "net device tx handler (hard_start_xmit) return code ?"
- Next in thread: David Woodhouse: "Re: net device tx handler (hard_start_xmit) return code ?"

On Fri, 5 Dec 1997, Michael Tross wrote:

> we have written a linux network device driver with an ethernet interface,
>developed using the skeleton device driver. But now - with kernel 2.0.34 -
>we ran into a problem with the transmit handler. My question is: what should
>be done in the transmit handler if the device is not ready to transmit
>another packet?

> 1. Return a value != 0 and say "Hey kernel, requeue this packet! I can't
> send now!" ? The effect I saw then was that the machine locks up with
> interrupts disabled.

This is the correct action.
You should make certain that dev->tbusy is set if you return a non-zero
value.

Note: The queue layer might still occasionally try to send you a packet even
with 'tbusy' set. This is used to implement Tx-timeouts -- checking for
transmitter hangs. The historical reason for doing this was that no
dynamically allocated general-purpose timer routines were available in old
kernels. Why do Ethernet cards, especially old ethernet cards, hang? They
have to deal with synchronizing fast asynchronous subsystems -- something
theoretically impossible to do reliably, and empirically difficult circuits
to design.

> 2. Return 0 and say "Ok kernel, I sent this packet (no one knows it's a
lie)!" ? This works, but it seems not to be the perfect solution.

It's evil because it just drops the packet.

Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html

- Next message: Shaw Carruthers: "Sound in 2.1.71"
- Previous message: Miquel van Smoorenburg: "Re: 2.1.71 failes to believe my VGA is usable as console"
- In reply to: Michael Tross: "net device tx handler (hard_start_xmit) return code ?"
- Next in thread: David Woodhouse: "Re: net device tx handler (hard_start_xmit) return code ?"