I've been going through the old work that Jens Axboe and I did for
PPPoATM to update it to the lastest kernel and fixing some bugs.
In particular I'm trying to do the correct thing WRT flow-control.
After reviewing the PPPoE code, I'm seriously suspecting that it's
wrong.
Background: each PPP channel (be it async, sync, PPPoE, PPPoA, etc)
provides a "chan.start_xmit" function which accepts outgoing packets.
This function returns a boolean value - if it returns false it means
that the channel cannot currently handle the packet and that it
should be retransmitted later. The channel has the responsibility
of calling ppp_output_wakeup() when more space is available.
PPPoE is L2-in-L2 encapsulation... it cannot support flow control.
Since it's dirrectly sending packets out an ethernet port, and it
may be only one of the protocols doing so, we cannot know a priori
whether a packet will be accepted in the ethernet's queue (although
dev_queue_xmit will return != NET_XMIT_SUCCESS) More importantly,
we don't have an idea of when we should try again. The proper way
of handling this is to just drop the packet and always return
success to the ppp_generic layer.
(Aside - the interested parties are invited to read the current
thread on VLANs on netdev for more debate than you ever wanted
about what to do with non-flow-control capable net_devices)
However, pppoe.c:__pppoe_xmit() acturally returns failure in
a host of different circumstances (including mundane ones like
being temporarily out of ram, or the ethernet being flooded),
the ppp_generic layer will queue up the packets. ppp_output_wakeup()
is never called by pppoe.c or pppox.c. Luckily it seems that
ppp_generic is fairly forgiving of this error, but it could
concievably cause problems, I think.
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.
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
