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 <qlyoung@cumulusnetworks.com>

diff --git a/bgpd/bgp_packet.c b/bgpd/bgp_packet.c
index c243f4b0e30ba11605e3e7c0455d685986f762a0..074b8313af5d1a71a8588372bd129bdbec9266c0 100644 (file)
--- 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;