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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34221C43334 for ; Thu, 21 Jul 2022 14:39:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231124AbiGUOjL (ORCPT ); Thu, 21 Jul 2022 10:39:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53190 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230056AbiGUOjD (ORCPT ); Thu, 21 Jul 2022 10:39:03 -0400 Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87CEE8688C for ; Thu, 21 Jul 2022 07:39:01 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id i4so1307493qvv.7 for ; Thu, 21 Jul 2022 07:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=kwW27VCQ4+JlDB+iPSDhz5O1D0eurbd7dKtxO/dfIvY=; b=OnzKBTMKPt8ybqoDKEizFWOIZUwtYD8NVniERJQRrRBD+FC+PRdDYfR9tAPu3M63Wt JG3TqJzUoWvMaF0pCE36eey30fVsLVvODRU/er7wla8BCkhleJfMm7QLgdvrEynQfv7f D64FKivghTNDU7lIbls+9rYw7bof/BUsEQ8+fzzuudi9b3k4wY3SXlIAk/SxIJOZJVCQ TzeoL49vw0ePEWJOK2s1Tu0Tc1DJW173uCXzh3pS7Xigojqp5Ood6OfscacTHVee07jq YdRhUB07YqVnhDr/fzI+/qAYhFgZvJyL8yNAyD2VsfUeuUe52gn2DhlXweRSZoq+fOeV FLgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kwW27VCQ4+JlDB+iPSDhz5O1D0eurbd7dKtxO/dfIvY=; b=fqg/ZjRpBui3W/xForf2VvUoPzeW3Cg/Lz9aqME+GVo3puoJvooeH7AKLgL4FS0P7f lRAfCx4g5jcr9BTTPUAU6s4mGRYtcyoqsLnyanvQ0ftn1naDuclN6EfL/lHf6TxiciFt y+YK3pjEqDzhfKNk27/5udLD6EzBH4ovMbnW1d6wrSjQjkDe0pMSoXfzxG5dk5lgC1Zb u8yOt9uxFHIO6lgRgFgKKOHXMdjTpFsO7uj2t+bIBq4QrxKW2/1jbx9ej8X2MfgGGswZ v5mihnyiGtRxjNaeT0R5vEV2JujoQkpNDuFNpjDfdIRrXjs23e2wr/PopbpVZaIX1Y2f 7Erg== X-Gm-Message-State: AJIora8DVpmMdSqOw8KZKdfj65zGWd9+aeHuRwsDgcne6PlwfzEHtzIb gfR3OV7FwpPHyQmuY+LLHsOL8w== X-Google-Smtp-Source: AGRyM1uWQJMIGs0cFKjzk6jOPxy6nU58JEm7wrsssEUVgVK/vH4DFVTrvRD0ZbRcmdLePWGA232yJQ== X-Received: by 2002:ad4:4ea2:0:b0:473:6d91:6759 with SMTP id ed2-20020ad44ea2000000b004736d916759mr34926483qvb.102.1658414340714; Thu, 21 Jul 2022 07:39:00 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id e19-20020a05620a12d300b006b5905999easm1403705qkl.121.2022.07.21.07.38.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jul 2022 07:38:59 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1oEXKM-001wqY-N5; Thu, 21 Jul 2022 11:38:58 -0300 Date: Thu, 21 Jul 2022 11:38:58 -0300 From: Jason Gunthorpe To: Long Li Cc: Dexuan Cui , KY Srinivasan , Haiyang Zhang , Stephen Hemminger , Wei Liu , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Leon Romanovsky , "edumazet@google.com" , "shiraz.saleem@intel.com" , Ajay Sharma , "linux-hyperv@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" Subject: Re: [Patch v4 03/12] net: mana: Handle vport sharing between devices Message-ID: <20220721143858.GV5049@ziepe.ca> References: <1655345240-26411-1-git-send-email-longli@linuxonhyperv.com> <1655345240-26411-4-git-send-email-longli@linuxonhyperv.com> <20220720234209.GP5049@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 21, 2022 at 12:06:12AM +0000, Long Li wrote: > > Subject: Re: [Patch v4 03/12] net: mana: Handle vport sharing between > > devices > > > > On Tue, Jul 12, 2022 at 06:48:09PM +0000, Long Li wrote: > > > > > @@ -563,9 +581,19 @@ static int mana_cfg_vport(struct > > > > > mana_port_context *apc, u32 protection_dom_id, > > > > > > > > > > apc->tx_shortform_allowed = resp.short_form_allowed; > > > > > apc->tx_vp_offset = resp.tx_vport_offset; > > > > > + > > > > > + netdev_info(apc->ndev, "Configured vPort %llu PD %u DB %u\n", > > > > > + apc->port_handle, protection_dom_id, doorbell_pg_id); > > > > Should this be netdev_dbg()? > > > > The log buffer can be flooded if there are many vPorts per VF PCI > > > > device and there are a lot of VFs. > > > > > > The reason netdev_info () is used is that this message is important > > > for troubleshooting initial setup issues with Ethernet driver. We rely > > > on user to get this configured right to share the same hardware port > > > between Ethernet and RDMA driver. As far as I know, there is no easy > > > way for a driver to "take over" an exclusive hardware resource from > > > another driver. > > > > This seems like a really strange statement. > > > > Exactly how does all of this work? > > > > Jason > > "vport" is a hardware resource that can either be used by an > Ethernet device, or an RDMA device. But it can't be used by both at > the same time. The "vport" is associated with a protection domain > and doorbell, it's programmed in the hardware. Outgoing traffic is > enforced on this vport based on how it is programmed. Sure, but how is the users problem to "get this configured right" and what exactly is the user supposed to do? I would expect the allocation of HW resources to be completely transparent to the user. Why is it not? Jason