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=-2.5 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT 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 C1659C10F0B for ; Thu, 18 Apr 2019 07:23:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 830DC2184B for ; Thu, 18 Apr 2019 07:23:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=resnulli-us.20150623.gappssmtp.com header.i=@resnulli-us.20150623.gappssmtp.com header.b="rtnrs+eC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730308AbfDRHXA (ORCPT ); Thu, 18 Apr 2019 03:23:00 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:45431 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725886AbfDRHW7 (ORCPT ); Thu, 18 Apr 2019 03:22:59 -0400 Received: by mail-wr1-f67.google.com with SMTP id s15so1579262wra.12 for ; Thu, 18 Apr 2019 00:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=MxaSuMXK01eYgIJOqvoaRcOP/kUU9NRqxzvJoOIMS3E=; b=rtnrs+eCQC5ABggz60xg3pI0kv3ouAG2RB+p+FiQioYOZUhx3AwsdtlrOR3QOK0yec k/ZDi1UF5wVSiV2kNtDGUXIz9jxdWjcS57va7iMIsD13PCRmNVUiXHj8826HGaiMLPLq cT4IbHCP7uks02dv6iuPiUCNJr0Maq5LiHVnEk1ta8KKIPjSRTc59qDTbvDC75krWCT8 V+ZTJTc5Iqfu+wmX1WZ8rSrQh5ednX9yOJQpfPvh+C/rWSPBVRLITFfeZFzMJ+MvibET aTEHazQ7Vkro8Eyj3bRxYozqz/cjz16DLvFiRM1DU66Me4WQJzFysWFOkJKP2TlXHERl B3iw== 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:references :mime-version:content-disposition:in-reply-to:user-agent; bh=MxaSuMXK01eYgIJOqvoaRcOP/kUU9NRqxzvJoOIMS3E=; b=TIsStsi3rl/0NLsQxDmnkBykFXWVkE2KbML637Kz7hNuI6TsUVpDSXBy4t+kfvlObE +cBeOpUPtRInpwLOCk+C6+3o0zBrF1roCY7sbgqqqJD6DY5BzhS8NkAVsoG/Vq6NEf6V P0SbaaSstM+OljA0S1ttowQZs35CygdEcbDoiVPYPhrv4rb6SJl3EUer+olqspWvxnyN zpKuPVK+SjtiuuAmnzfUUe450yX3pfw1n1bq5MGzIhx8KijcD1OnD31TZt5X+tWVzxF6 GAtK3RYrAd2cPbiw+Ah7GTudTOIiloMpGumJrR6PXGqpyXdJZLu83aOr0uWaxs/eEHDB ZceQ== X-Gm-Message-State: APjAAAWnZbe5u5LE4MMm+seJWe+Az4RFUCZJnmwYYAS9/CNxBIFPmAAY cqMd8npVB/ymSZd3OyQ/viXmisJ4njY= X-Google-Smtp-Source: APXvYqxbR4jt0hF9EspNvemJcd7oOD4RgKxcR6HNOYvW0nBlG9lVnSzHV6YmJutCP/wWJRnIqK6nHQ== X-Received: by 2002:adf:97c5:: with SMTP id t5mr44624633wrb.252.1555572178155; Thu, 18 Apr 2019 00:22:58 -0700 (PDT) Received: from localhost (jirka.pirko.cz. [84.16.102.26]) by smtp.gmail.com with ESMTPSA id d6sm1076754wrp.9.2019.04.18.00.22.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 18 Apr 2019 00:22:57 -0700 (PDT) Date: Thu, 18 Apr 2019 09:22:56 +0200 From: Jiri Pirko To: Jakub Kicinski 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: <20190418072256.GA2196@nanopsycho.orion> References: <20190413162112.8203-1-jiri@resnulli.us> <20190415122709.45dd4b09@cakuba.netronome.com> <20190416085937.GC2122@nanopsycho> <20190416110459.35b4b674@cakuba.netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190416110459.35b4b674@cakuba.netronome.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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? >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.. >"port splitting" or device slicing, which should be discussed over real >code, not netdevsim.