From patchwork Mon Mar 6 20:16:59 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Joe Stringer X-Patchwork-Id: 735923 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3vcWL22H0Cz9sDb for ; Tue, 7 Mar 2017 07:17:29 +1100 (AEDT) Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id EF6BFB79; Mon, 6 Mar 2017 20:17:26 +0000 (UTC) X-Original-To: dev@openvswitch.org Delivered-To: ovs-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5E104B78 for ; Mon, 6 Mar 2017 20:17:25 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C1435172 for ; Mon, 6 Mar 2017 20:17:24 +0000 (UTC) Received: from mfilter37-d.gandi.net (mfilter37-d.gandi.net [217.70.178.168]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 48E78A80D1 for ; Mon, 6 Mar 2017 21:17:23 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter37-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter37-d.gandi.net (mfilter37-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id uxTuRXPTWetB for ; Mon, 6 Mar 2017 21:17:21 +0100 (CET) X-Originating-IP: 209.85.220.175 Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) (Authenticated sender: joe@ovn.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 9639BA80D5 for ; Mon, 6 Mar 2017 21:17:21 +0100 (CET) Received: by mail-qk0-f175.google.com with SMTP id 1so173264971qkl.3 for ; Mon, 06 Mar 2017 12:17:21 -0800 (PST) X-Gm-Message-State: AMke39k415KfyK2QsbidhUI8XdunkPdOfAJVPlc9Bn3KQZSbHXixWN8te0U327C1m6J/kQUPRGunX2Uvu2dt8Q== X-Received: by 10.200.4.168 with SMTP id s40mr19217424qtg.283.1488831440318; Mon, 06 Mar 2017 12:17:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.163.229 with HTTP; Mon, 6 Mar 2017 12:16:59 -0800 (PST) In-Reply-To: References: From: Joe Stringer Date: Mon, 6 Mar 2017 12:16:59 -0800 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?B?TWlrYSBWw6Rpc8OkbmVu?= X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: ovs dev Subject: Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: Allow sending BFD messages even when RSTP port is not forwarding X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ovs-dev-bounces@openvswitch.org Errors-To: ovs-dev-bounces@openvswitch.org On 20 February 2017 at 04:27, Mika Väisänen wrote: > Interworking of BFD and RSTP does not work, as currently BFD messages are > dropped if RSTP port is not in forwarding mode. To correct this problem, > an extra check is added to allow BFD messages to be sent even when > rstp_forward_state is false. > > Note: This patch is made against branch-2.5. > > Signed-off-by: Mika Vaisanen > > --- There's something a bit off about the formatting of the patch, but it's simple enough that I can just make the equivalent change locally. The test seems to show the expected behaviour well. I see now, looking at the codepaths, the bfd packet generation link through to the compose_output_action() goes like this: monitor_mport_run() ofproto_dpif_send_packet() xlate_send_packet() ofproto_dpif_execute_actions() ofproto_dpif_execute_actions__() xlate_actions() do_xlate_actions() xlate_output_action() compose_output_action() I didn't realise that when these various protocols (STP, RSTP, CFM, BFD, etc.) send packets from OVS, it goes through the standard translation like this. I guess it makes sense :-) The only concern I had about this patch is if there was a way to end up broadcasting BFD in a loop because BFD is skipping past the STP/RSTP forwarding checks. However, I believe that on receive, xlate_actions() will handle BFD via process_special(), so typically it should not end up in the path where it's attempting to forward the packet. If it somehow does get past there, the check that is being added by this patch will ensure that the BFD packet matches the settings for this link, or otherwise it will respect the STP/RSTP forwarding state. So I think it's fine. I wouldn't mind bouncing it off someone like Jarno just to double-check my reasoning. As a matter of style, I think this diff in ofproto-dpif-xlate.c is a little easier to follow---and would cover the CFM case as well: !xport_rstp_forward_state(xport)) { if (ctx->xbridge->stp != NULL) { Acked-by: Jarno Rajahalme diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c index 89fc3a44a0d1..578fef168b30 100644 --- a/ofproto/ofproto-dpif-xlate.c +++ b/ofproto/ofproto-dpif-xlate.c @@ -3127,6 +3127,10 @@ compose_output_action__(struct xlate_ctx *ctx, ofp_port_t ofp_port, } return; } + } else if ((xport->cfm && cfm_should_process_flow(xport->cfm, flow, wc)) + || (xport->bfd && bfd_should_process_flow(xport->bfd, flow, + wc))) { + /* Pass; STP should not block link health detection. */ } else if (!xport_stp_forward_state(xport) ||