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 0D317C43381 for ; Thu, 21 Mar 2019 16:25:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BF611218E2 for ; Thu, 21 Mar 2019 16:25:05 +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="yLG4pLia" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728157AbfCUQZE (ORCPT ); Thu, 21 Mar 2019 12:25:04 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:44821 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726787AbfCUQZE (ORCPT ); Thu, 21 Mar 2019 12:25:04 -0400 Received: by mail-wr1-f66.google.com with SMTP id w2so7261168wrt.11 for ; Thu, 21 Mar 2019 09:25:03 -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=kTuur1nvM1hm0A9tYuR+eBDFSXOn9GNKugrMaFISUjg=; b=yLG4pLia+ACZEeoHDMeE3YuRBf8urpqKAjRMBYeOw2KWlRH+2GDATRXSqUGONiZrNd pb6tKEHRvn2bA6m0FTAS7ArJhr+jdk94dW3o2L7dkicB3SXb1lrDnM/1PaDYkAQLNgeP oT5urGCwtLml0UhZIIDlqVrB0Sp5QA/LteQ6ZSkf7KFenwOookUX4LhKR/qMAdh3bqut jCu1zWPQTTjbWwo8sYrSmep7Cuee3lvwtBIT4zP1CAMsgko3sGkn52LGVUTPIANvj98G OIVmsdn85+LtJQDgnaSsuU6l6EWWCdD+oGSzKgkYcI1kKqznnEcUP0bsRKTjRFuxO/d9 y8dw== 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=kTuur1nvM1hm0A9tYuR+eBDFSXOn9GNKugrMaFISUjg=; b=B9B9vK0SnXUAce50wpuQPg76WquB+a2K6oYCWSKh7OlRWYoliWHMRdGblXq9Nc4txP 1gdKASmaDrIq/PBgMwLJt3+UCBn/1PikcWAh6XyMtTRF4MoRS8YyguRtdYPD9XXTclzH Nu4USUoB4n9WhmgK4Fu1Bm3DuRGfwm5r5APTw+RqKx3aVynw2+5v6X1nLxgwLKGOu8bj KAROwZeZO99QpH3uW2ZpIvmAHY1/Fb+vtrbXuAXlfTPZMUpq3MUYepTo/yoHONep7G7t Enp7leS6TLSg3VEKgMgKBZnO/4vZ2Y1FhULd5YfVgV/sbk2lFHghxSLnVDFTzlArEFAX RbGw== X-Gm-Message-State: APjAAAV1GhPNHYfeMb5/nHBZvOW6GeWYMq//FcaHj8lO0W/8QWho8bMG LmO9Dzh51IW2Lb/K/1j9XDi/MQ== X-Google-Smtp-Source: APXvYqzQek6i6/wQC5jkG9q5qmkqKpX935QCevBQyxD4C+DXv/y7cmxYbvYc1pSFWzsnUnsoR8dFCQ== X-Received: by 2002:adf:ff91:: with SMTP id j17mr826095wrr.114.1553185502379; Thu, 21 Mar 2019 09:25:02 -0700 (PDT) Received: from localhost ([195.39.71.253]) by smtp.gmail.com with ESMTPSA id x13sm5041969wrw.14.2019.03.21.09.25.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 21 Mar 2019 09:25:01 -0700 (PDT) Date: Thu, 21 Mar 2019 17:14:21 +0100 From: Jiri Pirko To: Parav Pandit Cc: Jakub Kicinski , "Samudrala, Sridhar" , "davem@davemloft.net" , "netdev@vger.kernel.org" , "oss-drivers@netronome.com" Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI ports Message-ID: <20190321161421.GR2087@nanopsycho> References: <4436da3d-4b99-f792-8e77-695d5958794d@intel.com> <20190315200814.GD2305@nanopsycho> <20190315134454.581f47ca@cakuba.netronome.com> <20190318121154.GG2270@nanopsycho> <20190318121642.74a56b7e@cakuba.netronome.com> <20190321084526.GA2087@nanopsycho> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Thu, Mar 21, 2019 at 04:14:53PM CET, parav@mellanox.com wrote: > > >> -----Original Message----- >> From: Jiri Pirko >> Sent: Thursday, March 21, 2019 3:45 AM >> To: Jakub Kicinski >> Cc: Parav Pandit ; Samudrala, Sridhar >> ; davem@davemloft.net; >> netdev@vger.kernel.org; oss-drivers@netronome.com >> Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI >> ports >> >> Mon, Mar 18, 2019 at 08:16:42PM CET, jakub.kicinski@netronome.com >> wrote: >> >On Mon, 18 Mar 2019 13:11:54 +0100, Jiri Pirko wrote: >> >> >> >2. flavour should not be vf/pf, flavour should be hostport, switchport. >> >> >> >Because switch is flat and agnostic of pf/vf/mdev. >> >> >> >> >> >> Not sure. It's good to have this kind of visibility. >> >> > >> >> >Yes, this subthread honestly makes me go from 60% sure to 95% sure >> >> >we shouldn't do the dual object thing :( Seems like Parav is >> >> >already confused by it and suggests host port can exist without >> >> >switch port :( >> >> >> >> Although I understand your hesitation, the host ports are also >> >> associated with the asic and should be under the devlink instance. >> >> It is just a matter of proper documentation and clear code to avoid >> >> confusions. >> > >> >They are certainly a part and belong to the ASIC, the question in my >> >mind is more along the lines of do we want "one pipe/one port" or is it >> >okay to have multiple software objects of the same kind for those >> >objects. >> > >> >To put it differently - do want a port object for each port of the ASIC >> >or do we want a port object for each netdev.. >> >> Perhaps "port" name of the object is misleading. From the beginning, I ment >> to have it for both switch ports and host ports. I admit that "host port" is a >> bit misleading, as it is not really a port of eswitch, but the counter part. But >> if we introduce another object for that purpose in devlink (like "partititon"), >> it would be a lot of duplication I think. >> >> Question is, do we need the "host port"? Can't we just put a relation to host >> netdev in the eswitch port. >> >Can you please explain how does it work for rdma for non sriov use case? >Do we have to create a fake eswitch object? Could you please provide details on "rdma for non sriov use case"? > >> So as you suggest, we would have >> devlink_port -+-- switch netdev/ibdev >> | >> +-- host netdev/ibdev >> > >How does this work for rdma to program single node_guid for dual port ibdev? >Did you actually read the recent example I showed in [1]? >[1] https://marc.info/?l=linux-netdev&m=155312521817191&w=2 >And why it doesn't address all the use cases of pf/vf/mdev, ibdev, netdev? > >> So the "weights" of both switch/host netdev/ibdev to devlink_port relations >> would be equivalent. >> >> Then, the devlink_port would represent the whole "pipe" with both ends. >> >> More I think about it, the more it makes sense to me...