> 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?
It won't. In almost any circumstance, a driver should drop a datagram
on PPPoE... after all, what if we're causing it?
> Although __pppoe_xmit returns false in several circumstances, in
> actuality it will only return false if the dev_queue_xmit has failed.
OK.
> 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?)
I don't think there is such a mechanism... even if there was, I don't
think it would be the right thing to do. Imagine 1000 PPPoE tunnels
all beating on eth0 - suddenly space becomes free in the queue, so
you wake them all up and so they can fight for the space and then
back off again. Ug.
Since you're dumping packets into a shared datagram transit and it
already has its own queue, I don't see what the benefit of having
another queue really is. So I think for PPPoE the simple solution
is the best - if there's no room in the outgoing ethernet's queue,
just drop the packet.
Again, its unforunate that the only way you can perform a drop is
to signal a "success" to the ppp_generic layer (and mess up the
interface stats), but that's not too tragic. I added the following to
the PPPoATM channel code:
#define DROP_PACKET 1
and I changed the error cases where I would drop the packet to return
that. At least then when (and if... paulus?) the ppp_generic layer
gets the ability to signal a drop it'll be easy to update the
channel code.
So basically, I think the PPPoE start_xmit should never return 0 -
it should only return '1' or 'DROP_PACKET' (i.e. 1 :-)
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
