>
> Paul - I think the chan.start_xmit() should support a "dropped"
> return .. instead of throttling the interface and queuing the
> packet, we should continue as if it had succeeded, but increment
> ppp->stats.tx_dropped instead of ppp->stats.tx_{pakcets,bytes}.
> This is the correct way to handle PPPoE problems, and is probably
> the best thing for any channel to do on ENOMEM conditions or
> similar.
>
I agree. The alternative IMO is to have the PPPoE layer keep the skb
and retry at some other time. How else is it going to know that
something such as an ENOMEM condition has cleared?
Although __pppoe_xmit returns false in several circumstances, in
actuality it will only return false if the dev_queue_xmit has failed.
The other instances are all representative of situations that will not
occur if the channel has been properly configured --- they are there
only for completeness. For example, the skb copy should never
actually occur, since the generic layer has been told to leave enough
room for the PPPoE/ethernet header.
It has been my assumption all along that flow control issues should be
left to the generic PPP layer and higher-level protocols (TCP) as my
understanding of the PPPoE protocol is that it is simply an
encapsulation protocol. The RFC does not address anything related to
PPP at all --- PPPoE is not PPP specific.
All that being said, it would not be hard to try to periodically
re-transmit a frame if dev_queue_xmit() fails, and call
ppp_output_wakeup() on success. (Is there any sort of mechanism which
would notify me that queue space for a device has cleared up?)
Michal Ostrowski
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
