From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85459C43381 for ; Wed, 27 Mar 2019 22:49:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 446F920657 for ; Wed, 27 Mar 2019 22:49:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="3jRgBEoh" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728098AbfC0WtO (ORCPT ); Wed, 27 Mar 2019 18:49:14 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:41000 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726176AbfC0WtO (ORCPT ); Wed, 27 Mar 2019 18:49:14 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2RMn5cg110020; Wed, 27 Mar 2019 22:49:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : references : cc : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=e916VrTx+XI9mbCF3/nsYLlB8t3ju8NvjZFiAx7EaT8=; b=3jRgBEohlNEXaTIjQbmne7JYJhHy1Wt7BjqKT42+6BJPgkMvuRf7AwmuC9LPnBTu9x80 Cx6Lco6pzSzhpVy4njDe9LgQI3yVhR/u71tMJSM/zyxvvGPlhzY7LTmGczQ2s1A4WvXM oeV4KPfryS6gnxsDNMrx6R583ZtrptP+HlYM7LzNgT7oMoV7Kb3ZjWNFK7T7uGiCY+Zt /JKhNAGLN/9Hf6AB5xPVO3Cxp2NSdCTMBoUEfU8pWJAWE8dlstMYtP+fi+SCEsbpF6lj dGcDGz+Z0KTjUWz4WO38Bte2cN8am2/RoqwCyYdoo8QAHNRKnAY22LBmyesl0sEOPQ5G hQ== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2re6g1bdrs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Mar 2019 22:49:05 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x2RMn3Cw015241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Mar 2019 22:49:03 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x2RMn1bf023336; Wed, 27 Mar 2019 22:49:01 GMT Received: from [10.159.236.24] (/10.159.236.24) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Mar 2019 15:49:01 -0700 Subject: Re: [PATCH net v3] failover: allow name change on IFF_UP slave interfaces To: "Michael S. Tsirkin" References: <1553644093-10917-1-git-send-email-si-wei.liu@oracle.com> <20190326191342.11f0cb55@shemminger-XPS-13-9360> <20190327092424-mutt-send-email-mst@kernel.org> <20190327181433-mutt-send-email-mst@kernel.org> <97fcde0d-4a2d-5dbf-b735-de07245e0c4b@oracle.com> Cc: Stephen Hemminger , sridhar.samudrala@intel.com, davem@davemloft.net, kubakici@wp.pl, alexander.duyck@gmail.com, jiri@resnulli.us, netdev@vger.kernel.org, virtualization@lists.linux-foundation.org, liran.alon@oracle.com, boris.ostrovsky@oracle.com, vijay.balakrishna@oracle.com From: si-wei liu Organization: Oracle Corporation Message-ID: <6562a2bf-72f7-92b6-8a34-489aab6884ce@oracle.com> Date: Wed, 27 Mar 2019 15:48:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <97fcde0d-4a2d-5dbf-b735-de07245e0c4b@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9208 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=606 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903270156 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 3/27/2019 3:31 PM, si-wei liu wrote: > > > On 3/27/2019 3:16 PM, Michael S. Tsirkin wrote: >> On Wed, Mar 27, 2019 at 01:10:10PM -0700, si-wei liu wrote: >>> Another less safer option is that we just notify userspace anyway >>> without >>> sending down/up event around, as I don't see *any real application* >>> cares >>> about the link state or whatsoever when it attempts to detect rename. >> How do you write a race ree handler then? ATM just detecting link up is >> sufficient and covers 100% of cases. Seems like a good idea to keep it >> that way. >> > What do you mean? Which flag or attribute do you think 100% of the > userspace regard it as link up? And why userspace that cares about > name change needs to double check whether link is up or not? I'm > sorry, but are you sure this is the 100% case that every userspace app > does it like what you're claiming? > > -Siwei To me even the any flag checking regarding link state is unnecessary as it's hard for userspace apps to follow precisely the name change together with the link state. I'm not sure if you still persist in sending link down/up event. What the userspace apps that care about the name so far as I see chase the name through ifindex. I'm really doubtful if link state is that important to them. But if you really need that consistency I'd say bouncing the link is perhaps the only safe option. -Siwei