From 3b73658c7cc5df1306a71ae014425294714c12f1 Mon Sep 17 00:00:00 2001 From: Quentin Young Date: Tue, 13 Jun 2017 19:06:51 +0000 Subject: [PATCH] bgpd: lift read-quanta restriction Per previous work to ensure all FSM state is updated after processing each message, read-quanta should be safe to set > 1. Signed-off-by: Quentin Young --- bgpd/bgp_packet.c | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/bgpd/bgp_packet.c b/bgpd/bgp_packet.c index c243f4b0e3..074b8313af 100644 --- a/bgpd/bgp_packet.c +++ b/bgpd/bgp_packet.c @@ -2079,22 +2079,6 @@ int bgp_process_packet(struct thread *thread) rpkt_quanta_old = atomic_load_explicit(&peer->bgp->rpkt_quanta, memory_order_relaxed); - /* - * XXX: At present multiple packet reads per input cycle are - * problematic. The issue is that some of the packet processing - * functions perform their own FSM checks, that arguably should be - * located in bgp_fsm.c. For example if we are in OpenConfirm process a - * Keepalive, then a keepalive-received event is placed on the event - * queue to handle later. If we then process an Update before that - * event has popped, the update function checks that the peer status is - * in Established and if not tears down the session. Therefore we'll - * limit input processing to 1 packet per cycle, as it traditionally - * was, until this problem is rectified. - * - * @qlyoung June 2017 - */ - rpkt_quanta_old = 1; - /* Guard against scheduled events that occur after peer deletion. */ if (peer->status == Deleted || peer->status == Clearing) return 0; -- 2.39.5