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.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,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 821B5C10F14 for ; Thu, 18 Apr 2019 17:07:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4DA902171F for ; Thu, 18 Apr 2019 17:07:57 +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="nJydRN4p" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389473AbfDRRH4 (ORCPT ); Thu, 18 Apr 2019 13:07:56 -0400 Received: from mail-qk1-f194.google.com ([209.85.222.194]:43503 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733192AbfDRRHz (ORCPT ); Thu, 18 Apr 2019 13:07:55 -0400 Received: by mail-qk1-f194.google.com with SMTP id c20so1558538qkc.10 for ; Thu, 18 Apr 2019 10:07:54 -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=Reexcor4yVKjS2Db4NXo48340+ErALgsAlbh/Pq6lq8=; b=nJydRN4pwN8hjJrJHfzNRsYcEKEkxADnZhdURiBmG32zDDfhQSthykqPLzG/KSTMe0 s9D9nEtNT3JFePwMsWlOnrNcAVpCgL7abpl9yTbpCqcx4q3V6ZkSeR+CVoF63a1ebk5D mW5+yYYo7c0MWFo7ibRihUC4LGnOhyk5coabp8FLefLsT1aIE+S7AIduw4nltUXb9Duk z/+5OiS8TvLzhB4AOJBcvaxTT+SEMnnYzdtpj+RgzEzo2jkHg/rw0+8+JG0tpx0JQyFP CMbG/EQYop98KTNxQCIOXmoWVN5NFUtp2Y7EgfQGzzycJygI3YfxfpK45LJdXLOYHNkT t9Gg== 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=Reexcor4yVKjS2Db4NXo48340+ErALgsAlbh/Pq6lq8=; b=QC4EKUmPOpX+2No7JRdyptTkYt7RaEbAJREjnvhOegZjwhc2Y+FUQDAe1NWVIgPXR0 E1gD3hIULNfnb32fFMHVbFBx+8bcys334/oUFr2WD/kaama8VmPjI4Z+WddjibycUsnU iTTpWhTpQcbT86z6xpFqkREKYT8HqpXL/NGNWZ+UuFPmA3oCW6S22qf2PPArIeO0WjkI ZsFSLve5LK1In8ZuDnNedfj8BQGc0kKcnUa9UwIjqJnb1DRoUAvnmoJvkAD2xqVJFIMy /rQNezsS/J5nPg5G8mF9pofabP57OwMBpM6gLkTFcxG0Q37lb6dHFyYKgyJYswGpKycR zT2Q== X-Gm-Message-State: APjAAAUZI+gJK75UesXfinW3+k8NZpFCUnXjQZkDP40GBdiSJjHPqmpy lIQsSviJ4UDVTKCAfwnk13nxrAColdU= X-Google-Smtp-Source: APXvYqzz5qnYduSlfaLFdVedcsUgkWZOn1pyJoFbdF90RYQFM2VbBQd8BQtf+MrMLDvx0bunXpA75w== X-Received: by 2002:a05:620a:1665:: with SMTP id d5mr761633qko.319.1555607274358; Thu, 18 Apr 2019 10:07:54 -0700 (PDT) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id 6sm1843337qtt.8.2019.04.18.10.07.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 18 Apr 2019 10:07:54 -0700 (PDT) Date: Thu, 18 Apr 2019 10:07:48 -0700 From: Jakub Kicinski To: Jiri Pirko Cc: netdev@vger.kernel.org, davem@davemloft.net, mlxsw@mellanox.com Subject: Re: [patch net-next rfc 00/15] netdevsim: impement proper device model Message-ID: <20190418100748.04efa546@cakuba.netronome.com> In-Reply-To: <20190418072256.GA2196@nanopsycho.orion> References: <20190413162112.8203-1-jiri@resnulli.us> <20190415122709.45dd4b09@cakuba.netronome.com> <20190416085937.GC2122@nanopsycho> <20190416110459.35b4b674@cakuba.netronome.com> <20190418072256.GA2196@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 Thu, 18 Apr 2019 09:22:56 +0200, Jiri Pirko wrote: > Tue, Apr 16, 2019 at 08:04:59PM CEST, jakub.kicinski@netronome.com wrote: > >On Tue, 16 Apr 2019 10:59:37 +0200, Jiri Pirko wrote: > >> >> 4) netdevsim instances are created by "ip link add" which is great for > >> >> soft devices with no hw backend. The rtnl core allocates netdev and > >> >> calls into driver holding rtnl mutex. For hw-backed devices, this > >> >> flow is wrong as it breaks order in which things are done. > >> >> > >> >> This patchset adjust netdevsim to fix all above. > >> >> > >> >> In order to support proper devlink and devlink port instances and to be > >> >> able to emulate real devices, there is need to implement bus probe and > >> >> instantiate everything from there. User can specify device id and port > >> >> count to be instantianted. For example: > >> >> > >> >> echo "10 4" > /sys/bus/netdevsim/new_device > >> > > >> >I really don't like the design where ID has to be allocated by user > >> >space. It's a step back. > >> > > >> >I also dislike declaring ports from the start. In real drivers ports > >> >are never "atomically" registered, they are crated and destroyed one > >> > >> Care to define "atomically" here? It is done in a very similar way > >> to how it is done in mlxsw for example. Same flows. > >> > >> > >> >by one, and a lot of races/UAFs/bugs lie in those small periods of > >> >time where one netdev got unregistered, but other are still around... > >> > >> Same here. Not sure where do you see the differences. > > > >The difference is that today I can do this: > > > >create a netdevsim1 with shared dev 1 > >create some state associated with shared dev 1 > >create a netdevsim2 with shared dev 1 > >check if all the shared dev 1 state created for netdevsim1 is visible > > via netdevsim2 > > Hmm, you are testing netdevsim implementation then, not the kernel > interfaces. What is the point of testing netdevsim? BPF offload tries to leave as much code as possible in the core, and make the drivers simple. I'm testing whether the core reacts correctly, netdevsim just calls register/unregister. > >destroy netdevsim1 > >check the shared dev 1 state again > > > >If I say "give me 2 ports" from the start, that makes the testing > >(which is the whole point of this code) harder. > > > >> Also, I plan to implement port splitting in follow-up patchset. All > >> flows are there as well. > > > >Sure, let's just be clear that we won't be merging an ABI that has just > >a netdevsim implementation, right? I have some reservations about the > > So what do you suggest? Allow to somehow add and remove ports during > test? You can already do that with VFs. Do you want to do that with > netdevsim "physical" ports? If yes, how? I can imagine to extend devlink > port api with something like: > > $ sudo devlink dev > netdevsim/netdevsim0 > $ sudo devlink port > netdevsim/netdevsim0/0: type eth netdev eth0 flavour physical > > $ sudo devlink dev port add netdevsim/netdevsim0 index 22 > $ sudo devlink port > netdevsim/netdevsim0/0: type eth netdev eni0p1 flavour physical > netdevsim/netdevsim0/22: type eth netdev eni0p23 flavour physical > > $ sudo devlink port del netdevsim/netdevsim0/0 > $ sudo devlink port > netdevsim/netdevsim0/22: type eth netdev eni0p23 flavour physical > > But I see only usecase for this extension for netdevsim, not for real > devices.. Hm.. I'm getting lost, sorry, I'm probably confusing myself here.. Netdevsim is supposed to test real, existing kernel interfaces and core code. What we do today with linking based on netdevs is quite simple and works very well for the BPF offload tests. If you want to test some devlink code, that's also real, perfect. For BPF tests we want the ability to add and remove netdevs to a sdev during tests, yes. That ability cannot be lost. > >"port splitting" or device slicing, which should be discussed over real > >code, not netdevsim.