Arne Lie
2008-09-09 19:44:49 UTC
Hi,
We are implementing a system (basically a modem operating as a router) with
embedded Linux (currently v2.6.25.16) where tailor made communication
between the embedded platforms happens over PPP (in addition to Ethernet
interfaces also available). Due to specialized hardware, we have developed
our own PPP driver. This is not a *network* driver, but instead a *char*
driver. I.e. we let our PPP talk with a serial tty interface (emulating an
UART interface). This interface is now working.
However, in periods of traffic overload, packet drops happens *inside* the
PPP system, and not in the Linux forwarding TCP/IP queue system. This is not
good because we now want to use advanced queuing systems supporting DiffServ
(using tc). The driver has a queue length internally of 5 packets, and
returns EAGAIN when queue is full (the driver operates in non-blocking
mode). It looks like the PPP layer above do not try to resubmit the packet,
but turns to dropping instead. Because of this, the ppp0 interface looks
like a high-rate interface, and the Linux queuing system never backlogs as
it should.
We are unsure if any netif_stop_queue/netif_wake_queue functionality is used
by the PPP upper layers. We would be happy to receive any suggestions.
Best regards,
Arne Lie
SINTEF ICT, Dept. of Communication Systems
e-mail: ***@sintef.no
PS:
The PPP is started with:
pppd /dev/pppfifo0
(pppfifo is the name of the device tty driver) and the options file includes
noctsrts
lock
passive
In our pppfifo driver we have implemented:
.throttle = pppfifo_throttle, (but it does not stop new data coming...)
.unthrottle = pppfifo_unthrottle,
.stop = pppfifo_stop,
.start = pppfifo_start
and in addition:
.tiocmget = pppfifo_tiocmget,
.tiocmset = pppfifo_tiocmset,
We observe some ioctrl messages, but have not decoded them yet. Perhaps we
need a detailed look at these?
We are implementing a system (basically a modem operating as a router) with
embedded Linux (currently v2.6.25.16) where tailor made communication
between the embedded platforms happens over PPP (in addition to Ethernet
interfaces also available). Due to specialized hardware, we have developed
our own PPP driver. This is not a *network* driver, but instead a *char*
driver. I.e. we let our PPP talk with a serial tty interface (emulating an
UART interface). This interface is now working.
However, in periods of traffic overload, packet drops happens *inside* the
PPP system, and not in the Linux forwarding TCP/IP queue system. This is not
good because we now want to use advanced queuing systems supporting DiffServ
(using tc). The driver has a queue length internally of 5 packets, and
returns EAGAIN when queue is full (the driver operates in non-blocking
mode). It looks like the PPP layer above do not try to resubmit the packet,
but turns to dropping instead. Because of this, the ppp0 interface looks
like a high-rate interface, and the Linux queuing system never backlogs as
it should.
We are unsure if any netif_stop_queue/netif_wake_queue functionality is used
by the PPP upper layers. We would be happy to receive any suggestions.
Best regards,
Arne Lie
SINTEF ICT, Dept. of Communication Systems
e-mail: ***@sintef.no
PS:
The PPP is started with:
pppd /dev/pppfifo0
(pppfifo is the name of the device tty driver) and the options file includes
noctsrts
lock
passive
In our pppfifo driver we have implemented:
.throttle = pppfifo_throttle, (but it does not stop new data coming...)
.unthrottle = pppfifo_unthrottle,
.stop = pppfifo_stop,
.start = pppfifo_start
and in addition:
.tiocmget = pppfifo_tiocmget,
.tiocmset = pppfifo_tiocmset,
We observe some ioctrl messages, but have not decoded them yet. Perhaps we
need a detailed look at these?