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.2 required=3.0 tests=DKIMWL_WL_HIGH,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 7094DC43381 for ; Fri, 22 Feb 2019 07:55:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2F28F2086C for ; Fri, 22 Feb 2019 07:55:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="mr3LspWk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726272AbfBVHzn (ORCPT ); Fri, 22 Feb 2019 02:55:43 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:51918 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725855AbfBVHzn (ORCPT ); Fri, 22 Feb 2019 02:55:43 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1M7rSq5028571; Fri, 22 Feb 2019 07:55:31 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=ikZxRRh05PAZHLHP5c91c+EyBaMGD2ctPONFnm1evcg=; b=mr3LspWkbw15UcNmjQWxU4DQ2DZmw/DPLT6mTGwhlpnEgCx4uCOhlIFrWmd41nKgqlkJ soNAJoq3ue32cRWeQTIrBwNG5sulcMkJPWt3+uZqFV7UU3EleLQxIqfEvij13nZMJIMO 6/tnV4fpHaaBV1AtMJ2O64Z2PRlZplhczkjVVzl4WEWuw494xwEjD4VPiMSrOrvP1lMF 73YeMzrizPGUOri3GP2zGBmjGXtDRQUX6dIW7EO0t6HCfB0QasYSYQZs9u5NLpXX/Ip5 R/RKtCnkbFskR3ReVA0DKh2y47awgqVgVJvCMo2FuchJOCx3pO4zCA6U+/17Aqj0s1t+ Jw== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2qpb5rvndt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Feb 2019 07:55:31 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x1M7tTPE000565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Feb 2019 07:55:29 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x1M7tRYk004170; Fri, 22 Feb 2019 07:55:27 GMT Received: from [192.168.0.18] (/76.102.100.140) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 21 Feb 2019 23:55:26 -0800 Subject: Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework) To: "Samudrala, Sridhar" , "Michael S. Tsirkin" , Siwei Liu References: <1523386790-12396-1-git-send-email-sridhar.samudrala@intel.com> <1523386790-12396-5-git-send-email-sridhar.samudrala@intel.com> <20180410142608.50f15b45@xeon-e3> <20180411075334.GK2028@nanopsycho> <20190221203808-mutt-send-email-mst@kernel.org> <581e4399-3969-aecd-e923-03bbc0880733@oracle.com> <91d4cbb1-be7a-b53c-6b2a-99bef07e7c53@intel.com> Cc: Jiri Pirko , Stephen Hemminger , David Miller , Netdev , virtualization@lists.linux-foundation.org, virtio-dev , "Brandeburg, Jesse" , Alexander Duyck , Jakub Kicinski , Jason Wang , liran.alon@oracle.com From: si-wei liu Organization: Oracle Corporation Message-ID: Date: Thu, 21 Feb 2019 23:55:11 -0800 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: <91d4cbb1-be7a-b53c-6b2a-99bef07e7c53@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9174 signatures=668684 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902220055 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2/21/2019 11:00 PM, Samudrala, Sridhar wrote: > > > On 2/21/2019 7:33 PM, si-wei liu wrote: >> >> >> On 2/21/2019 5:39 PM, Michael S. Tsirkin wrote: >>> On Thu, Feb 21, 2019 at 05:14:44PM -0800, Siwei Liu wrote: >>>> Sorry for replying to this ancient thread. There was some remaining >>>> issue that I don't think the initial net_failover patch got addressed >>>> cleanly, see: >>>> >>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268 >>>> >>>> The renaming of 'eth0' to 'ens4' fails because the udev userspace was >>>> not specifically writtten for such kernel automatic enslavement. >>>> Specifically, if it is a bond or team, the slave would typically get >>>> renamed *before* virtual device gets created, that's what udev can >>>> control (without getting netdev opened early by the other part of >>>> kernel) and other userspace components for e.g. initramfs, >>>> init-scripts can coordinate well in between. The in-kernel >>>> auto-enslavement of net_failover breaks this userspace convention, >>>> which don't provides a solution if user care about consistent naming >>>> on the slave netdevs specifically. >>>> >>>> Previously this issue had been specifically called out when IFF_HIDDEN >>>> and the 1-netdev was proposed, but no one gives out a solution to this >>>> problem ever since. Please share your mind how to proceed and solve >>>> this userspace issue if netdev does not welcome a 1-netdev model. >>> Above says: >>> >>> there's no motivation in the systemd/udevd community at >>> this point to refactor the rename logic and make it work well with >>> 3-netdev. >>> >>> What would the fix be? Skip slave devices? >>> >> There's nothing user can get if just skipping slave devices - the >> name is still unchanged and unpredictable e.g. eth0, or eth1 the next >> reboot, while the rest may conform to the naming scheme (ens3 and >> such). There's no way one can fix this in userspace alone - when the >> failover is created the enslaved netdev was opened by the kernel >> earlier than the userspace is made aware of, and there's no >> negotiation protocol for kernel to know when userspace has done >> initial renaming of the interface. I would expect netdev list should >> at least provide the direction in general for how this can be solved... >> > Is there an issue if slave device names are not predictable? The user/admin scripts are expected > to only work with the master failover device. Where does this expectation come from? Admin users may have ethtool or tc configurations that need to deal with predictable interface name. Third-party app which was built upon specifying certain interface name can't be modified to chase dynamic names. Specifically, we have pre-canned image that uses ethtool to fine tune VF offload settings post boot for specific workload. Those images won't work well if the name is constantly changing just after couple rounds of live migration. > Moreover, you were suggesting hiding the lower slave devices anyway. There was some discussion > about moving them to a hidden network namespace so that they are not visible from the default namespace. > I looked into this sometime back, but did not find the right kernel api to create a network namespace within > kernel. If so, we could use this mechanism to simulate a 1-netdev model. Yes, that's one possible implementation (IMHO the key is to make 1-netdev model as much transparent to a real NIC as possible, while a hidden netns is just the vehicle). However, I recall there was resistance around this discussion that even the concept of hiding itself is a taboo for Linux netdev. I would like to summon potential alternatives before concluding 1-netdev is the only solution too soon. Thanks, -Siwei > >> -Siwei >> >>