Re: [PATCH net-next RFC] net: x25: Queue received packets in the drivers instead of per-CPU queues

2021-03-09 Thread Xie He
On Tue, Mar 9, 2021 at 5:23 AM Martin Schiller  wrote:
>
> I've tested the hdlc_x25 driver.
> Looks good to me.
>
> Acked-by: Martin Schiller 

Thank you!!

I'll re-send this patch after net-next is re-opened and my other fixes
get merged into net-next.

Thanks!


Re: [PATCH net-next RFC] net: x25: Queue received packets in the drivers instead of per-CPU queues

2021-03-09 Thread Martin Schiller

On 2021-03-05 06:43, Xie He wrote:

X.25 Layer 3 (the Packet Layer) expects layer 2 to provide a reliable
datalink service such that no packets are reordered or dropped. And
X.25 Layer 2 (the LAPB layer) is indeed designed to provide such 
service.


However, this reliability is not preserved when a driver calls 
"netif_rx"

to deliver the received packets to layer 3, because "netif_rx" will put
the packets into per-CPU queues before they are delivered to layer 3.
If there are multiple CPUs, the order of the packets may not be 
preserved.

The per-CPU queues may also drop packets if there are too many.

Therefore, we should not call "netif_rx" to let it queue the packets.
Instead, we should use our own queue that won't reorder or drop 
packets.


This patch changes all X.25 drivers to use their own queues instead of
calling "netif_rx". The patch also documents this requirement in the
"x25-iface" documentation.


I've tested the hdlc_x25 driver.
Looks good to me.

Acked-by: Martin Schiller 


[PATCH net-next RFC] net: x25: Queue received packets in the drivers instead of per-CPU queues

2021-03-04 Thread Xie He
X.25 Layer 3 (the Packet Layer) expects layer 2 to provide a reliable
datalink service such that no packets are reordered or dropped. And
X.25 Layer 2 (the LAPB layer) is indeed designed to provide such service.

However, this reliability is not preserved when a driver calls "netif_rx"
to deliver the received packets to layer 3, because "netif_rx" will put
the packets into per-CPU queues before they are delivered to layer 3.
If there are multiple CPUs, the order of the packets may not be preserved.
The per-CPU queues may also drop packets if there are too many.

Therefore, we should not call "netif_rx" to let it queue the packets.
Instead, we should use our own queue that won't reorder or drop packets.

This patch changes all X.25 drivers to use their own queues instead of
calling "netif_rx". The patch also documents this requirement in the
"x25-iface" documentation.

Cc: Martin Schiller 
Signed-off-by: Xie He 
---
 Documentation/networking/x25-iface.rst | 65 --
 drivers/net/wan/hdlc_x25.c | 29 +++-
 drivers/net/wan/lapbether.c| 46 --
 3 files changed, 79 insertions(+), 61 deletions(-)

diff --git a/Documentation/networking/x25-iface.rst 
b/Documentation/networking/x25-iface.rst
index df401891dce6..f34e9ec64937 100644
--- a/Documentation/networking/x25-iface.rst
+++ b/Documentation/networking/x25-iface.rst
@@ -70,60 +70,13 @@ First Byte = 0x03 (X25_IFACE_PARAMS)
 LAPB parameters. To be defined.
 
 
+Requirements for the device driver
+--
 
-Possible Problems
-=
-
-(Henner Eisen, 2000-10-28)
-
-The X.25 packet layer protocol depends on a reliable datalink service.
-The LAPB protocol provides such reliable service. But this reliability
-is not preserved by the Linux network device driver interface:
-
-- With Linux 2.4.x (and above) SMP kernels, packet ordering is not
-  preserved. Even if a device driver calls netif_rx(skb1) and later
-  netif_rx(skb2), skb2 might be delivered to the network layer
-  earlier that skb1.
-- Data passed upstream by means of netif_rx() might be dropped by the
-  kernel if the backlog queue is congested.
-
-The X.25 packet layer protocol will detect this and reset the virtual
-call in question. But many upper layer protocols are not designed to
-handle such N-Reset events gracefully. And frequent N-Reset events
-will always degrade performance.
-
-Thus, driver authors should make netif_rx() as reliable as possible:
-
-SMP re-ordering will not occur if the driver's interrupt handler is
-always executed on the same CPU. Thus,
-
-- Driver authors should use irq affinity for the interrupt handler.
-
-The probability of packet loss due to backlog congestion can be
-reduced by the following measures or a combination thereof:
-
-(1) Drivers for kernel versions 2.4.x and above should always check the
-return value of netif_rx(). If it returns NET_RX_DROP, the
-driver's LAPB protocol must not confirm reception of the frame
-to the peer.
-This will reliably suppress packet loss. The LAPB protocol will
-automatically cause the peer to re-transmit the dropped packet
-later.
-The lapb module interface was modified to support this. Its
-data_indication() method should now transparently pass the
-netif_rx() return value to the (lapb module) caller.
-(2) Drivers for kernel versions 2.2.x should always check the global
-variable netdev_dropping when a new frame is received. The driver
-should only call netif_rx() if netdev_dropping is zero. Otherwise
-the driver should not confirm delivery of the frame and drop it.
-Alternatively, the driver can queue the frame internally and call
-netif_rx() later when netif_dropping is 0 again. In that case, delivery
-confirmation should also be deferred such that the internal queue
-cannot grow to much.
-This will not reliably avoid packet loss, but the probability
-of packet loss in netif_rx() path will be significantly reduced.
-(3) Additionally, driver authors might consider to support
-CONFIG_NET_HW_FLOWCONTROL. This allows the driver to be woken up
-when a previously congested backlog queue becomes empty again.
-The driver could uses this for flow-controlling the peer by means
-of the LAPB protocol's flow-control service.
+Packets should not be reordered or dropped when delivering between the
+Packet Layer and the device driver.
+
+To avoid packets from being reordered or dropped when delivering from
+the device driver to the Packet Layer, the device driver should not
+call "netif_rx" to deliver the received packets. Instead, it should
+call "netif_receive_skb_core" from softirq context to deliver them.
diff --git a/drivers/net/wan/hdlc_x25.c b/drivers/net/wan/hdlc_x25.c
index 4aaa6388b9ee..28e9cb2c5f1e 100644
--- a/drivers/net/wan/hdlc_x25.c
+++ b/drivers/net/wan/hdlc_x25.c
@@ -23,6 +23,8 @@
 
 struct x25_state {
x25_hdlc_proto settings;
+