Controlling the transmit queue doesn’t seem to be mentioned in the 6.3.0
docs or sample drivers. Has this mechanism changed? Where is it
documented?
Murf
John Murphy <murf@perftech.com> wrote:
Controlling the transmit queue doesn’t seem to be mentioned in the 6.3.0
docs or sample drivers. Has this mechanism changed? Where is it
documented?
This behaviour still works, but it’s currently being deprecated.
It may be removed in the future.
The reason is to encourage driver writers to use the most efficient
throttling mechanism for a given device.
It’s easy to put code in the drivers transmit routine to do exactly
what io-net used to do when the MAX_QUEUE value was reached:
errno = ENOBUFS;
npkt->flags |= _NPKT_NOT_TXED;
mydev->ion->tx_done(my_dev->reg_hdl, npkt);
return TX_DOWN_FAILED;
Dave
OK, thanks! That’s what I suspected, but I wanted to be sure there
hadn’t been some fundamental architectural change.
How about the ENOLINK error when the line is down? That also seems to
be missing in the new drivers. Is the theory that no chip is going to
hang forever trying to send a packet?
Murf
David Donohoe wrote:
John Murphy <> murf@perftech.com> > wrote:
Controlling the transmit queue doesn’t seem to be mentioned in the 6.3.0
docs or sample drivers. Has this mechanism changed? Where is it
documented?
This behaviour still works, but it’s currently being deprecated.
It may be removed in the future.The reason is to encourage driver writers to use the most efficient
throttling mechanism for a given device.It’s easy to put code in the drivers transmit routine to do exactly
what io-net used to do when the MAX_QUEUE value was reached:errno = ENOBUFS;
npkt->flags |= _NPKT_NOT_TXED;
mydev->ion->tx_done(my_dev->reg_hdl, npkt);
return TX_DOWN_FAILED;Dave
John Murphy <murf@perftech.com> wrote:
How about the ENOLINK error when the line is down? That also seems to
be missing in the new drivers. Is the theory that no chip is going to
hang forever trying to send a packet?
It’s up to the driver whether it wants to drop the packet, or
put it on a queue, but the driver shouldn’t block if the link
is down.
Dave
I seem to recall seeing a fairly recent message about this that said
something to the effect that “some of the older drivers” would return
ENOLINK. Again, the implication was that there had been a change in
thinking regarding driver design - but I can’t locate the message!
Murf
David Donohoe wrote:
John Murphy <> murf@perftech.com> > wrote:
How about the ENOLINK error when the line is down? That also seems to
be missing in the new drivers. Is the theory that no chip is going to
hang forever trying to send a packet?It’s up to the driver whether it wants to drop the packet, or
put it on a queue, but the driver shouldn’t block if the link
is down.Dave
ENOLINK is a little drastic. Some protocols consider this
a hard error and won’t retry.
-seanb
John A. Murphy <murf@perftech.com> wrote:
I seem to recall seeing a fairly recent message about this that said
something to the effect that “some of the older drivers” would return
ENOLINK. Again, the implication was that there had been a change in
thinking regarding driver design - but I can’t locate the message!Murf
David Donohoe wrote:
John Murphy <> murf@perftech.com> > wrote:
How about the ENOLINK error when the line is down? That also seems to
be missing in the new drivers. Is the theory that no chip is going to
hang forever trying to send a packet?It’s up to the driver whether it wants to drop the packet, or
put it on a queue, but the driver shouldn’t block if the link
is down.Dave