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=-4.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED 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 96941C10F03 for ; Tue, 23 Apr 2019 17:05:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5A53921850 for ; Tue, 23 Apr 2019 17:05:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="rHwMuswg" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729309AbfDWRFg (ORCPT ); Tue, 23 Apr 2019 13:05:36 -0400 Received: from mail-qk1-f194.google.com ([209.85.222.194]:37600 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727740AbfDWRFg (ORCPT ); Tue, 23 Apr 2019 13:05:36 -0400 Received: by mail-qk1-f194.google.com with SMTP id c1so9053058qkk.4 for ; Tue, 23 Apr 2019 10:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=QoCXiFBhkG+GkCh3lIr7ind5Sb0eADUHT4YdK050Qe8=; b=rHwMuswgj8+aNteOIW8563hNLJmmwEQJyZ95agZzyv16UnCHMFHdN77JOs+qtM94vU 3oIV3+pJ+tcgPGSsSWXC4zzJIIhrSpOPaMR1D3CDT0vEZBEIDe5WLL1IdXOLJTjliWSW MK5MLxIj7p0ypVnIyDHLeR+njtvVckirJ0WV6veZbii+J0aH5R1sM2EX33yn6gZjSedA SSqr5ozcQOoj72PIQmx+SZkSNolQdanuSyVhQ5x1D1ZtOaJNY3NAj3QqztksUkPnd8u3 bylzNGKA/LW5dx4lybQbOTdQ9RfnCLrJ3dQs+UNkw5teLCnQzbFtZHrnn6mcdgumjeEt ySyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=QoCXiFBhkG+GkCh3lIr7ind5Sb0eADUHT4YdK050Qe8=; b=W0FSBJk8nv9m4yZKwzM4u8asBA2uCW2ouN4SGKA6898jOVNaj+5B+rOBJPAZYVPrhW 62iiKloK2EWYEoUW/mZeyUvlOnkpsgPniK5bGGePUUF6FPQvuhhvuhP1TDeZ8O9BpxGM yjRT6BJBWM+vX095bli7faHyllegl9Y2GbYOP1+8gZNETxKHsF1tf+uBVCUW5DMehb33 obKUMXbUKIHrVlA3LbOYz5qbv0qtudc+LFjYEeawxqAJXlGuwUIg52Bwno1wbrA48a9P 4VEEPRK3zLKgi1/dA+2Qj+T96mLGKd3CvRriuWtKQOVtceceXshvELlU3NNnUgcs8s4l pA6g== X-Gm-Message-State: APjAAAWYQWuYkfu5w+yBnSyE+tbkk0PWN96Qkw1uMY7eII/EsOChOZqu 6pkabjj2+VwRdpXxboVsTJWKWA== X-Google-Smtp-Source: APXvYqyIFq/PkbeKldKrtCXNbtNMqGd0O4SFOCqAS+5ciZiL+/4JRr6iN/Xyh26ny3ulzqaK9S0evw== X-Received: by 2002:a37:ef04:: with SMTP id j4mr18348209qkk.319.1556039134980; Tue, 23 Apr 2019 10:05:34 -0700 (PDT) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id d41sm10233233qtd.90.2019.04.23.10.05.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 23 Apr 2019 10:05:34 -0700 (PDT) Date: Tue, 23 Apr 2019 10:05:28 -0700 From: Jakub Kicinski To: Jiri Pirko Cc: netdev@vger.kernel.org, davem@davemloft.net, mlxsw@mellanox.com, dsahern@gmail.com Subject: Re: [patch net-next v2 15/16] netdevsim: move netdev creation/destruction to dev probe Message-ID: <20190423100528.48908627@cakuba.netronome.com> In-Reply-To: <20190423072014.GC2677@nanopsycho.orion> References: <20190420102922.6001-1-jiri@resnulli.us> <20190420102922.6001-16-jiri@resnulli.us> <20190422123133.161fb1a1@cakuba.netronome.com> <20190423072014.GC2677@nanopsycho.orion> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 23 Apr 2019 09:20:14 +0200, Jiri Pirko wrote: > Mon, Apr 22, 2019 at 09:31:33PM CEST, jakub.kicinski@netronome.com wrote: > >On Sat, 20 Apr 2019 12:29:21 +0200, Jiri Pirko wrote: > >> diff --git a/tools/testing/selftests/bpf/test_offload.py b/tools/testing/selftests/bpf/test_offload.py > >> index 5f2e4f9e70e4..a0566dcf064a 100755 > >> --- a/tools/testing/selftests/bpf/test_offload.py > >> +++ b/tools/testing/selftests/bpf/test_offload.py > >> @@ -1,6 +1,7 @@ > >> #!/usr/bin/python3 > >> > >> # Copyright (C) 2017 Netronome Systems, Inc. > >> +# Copyright (c) 2019 Mellanox Technologies. All rights reserved > > > >What's your guiding principle with adding those copyright lines > >everywhere? > > Semi-random :) I can remove it if you want. Technically I have no opinion, personally I find it petty and unnecessary in the git era.. Probably not worth your time now to go and remove :) > >> +class NetdevSim: > >> + """ > >> + Class for netdevsim netdevice and its attributes. > >> + """ > >> + > >> + def __init__(self, nsimdev, port_index): > >> + self.nsimdev = nsimdev > >> + self.port_index = port_index > >> + self.ns = "" > >> + self.dfs_dir = "%s/ports/%u/" % (nsimdev.dfs_dir, port_index) > >> + self.dfs_refresh() > >> + > >> + ifname = "eni%unp%u" % (nsimdev.addr, port_index + 1) > >> + timeout = 0.5 > >> + timeout_start = time.time() > >> + > >> + while True: > >> + try: > >> + _, [self.dev] = ip("link show dev %s" % ifname) > >> + except Exception as e: > >> + if time.time() < timeout_start + timeout: > >> + continue > >> + raise e > >> + break > > > >udevadm settle? The reliance on latest systemd is a real bad idea, > > Not sure that "udevadm settle" would help here. The diver bus probe handle > may be executed from a workqueue, so here, there might be the udev event > queue empty yet still the netdev is not present. Mm.. true. I must say I had a ton of issues with this in Netronome test systems, those "wait for renames" loop always broke no matter what.. OS upgrade, adding debug stuff into the kernel.. I get flashbacks. I've seen udev easily take 20s to rename on a heavy kernel. Since we replaced the loops with udevadm settle - it's been a bliss. YMMV but in my experience regardless of workqueues and all udev is way more reliable. > >could you fall back to netdevsimX names if eni$SOME$CUFT is not found? > > That would not help. If you have udev which does not support this, you > are going to endup with "eth0, eth1, .." That is not great :( The kbuild bot runs BPF offload tests, they run with some CentOS user space. If we don't want to name the device in the kernel, perhaps it'd be possible to scan sysfs? The ifc names should be under $device/net/, right?