From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6943CA0C46; Tue, 31 Aug 2021 17:42:07 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5681740142; Tue, 31 Aug 2021 17:42:07 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 4767040141 for ; Tue, 31 Aug 2021 17:42:06 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id C43307F57F; Tue, 31 Aug 2021 18:42:05 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru C43307F57F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1630424525; bh=Wfa8EPotcLpVFlOBnSUo/aZJ4ggNjpvJxn9KVqjBQUw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ecTl379nOmeSi5E/BmgLJVX0Gz0GALJVyuoMgayrQTS5BWJr3KhNy+2qcqomao9Gs WveTDJs45zp1fHsTWP74uL/3Beqp4iySEFmLAFoZvaFXVNVVhAZTAEcNkEDl6KqZNA Psy9mjX/9ENotGnvuq3EurxQ/wYQOWDfWnhNVXdE= To: "Xueming(Steven) Li" , Viacheslav Galaktionov Cc: Ajit Khaparde , Somnath Kotur , John Daley , Hyong Youb Kim , Beilei Xing , Qiming Yang , Qi Zhang , Haiyue Wang , Matan Azrad , Shahaf Shuler , Slava Ovsiienko , NBU-Contact-Thomas Monjalon , Ferruh Yigit , "dev@dpdk.org" References: <20210712161747.958019-1-andrew.rybchenko@oktetlabs.ru> <20210818140004.2812575-1-andrew.rybchenko@oktetlabs.ru> <9f94fd99973050392ba5c37f9dbacec0@oktetlabs.ru> <3880ab6a-2b3a-b8ef-bc5e-f6e9b5f43159@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Tue, 31 Aug 2021 18:42:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix representor port ID search by name X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 8/29/21 3:17 PM, Xueming(Steven) Li wrote: > > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Sunday, August 29, 2021 4:23 PM >> To: Xueming(Steven) Li ; Viacheslav Galaktionov >> Cc: Ajit Khaparde ; Somnath Kotur ; John Daley >> ; Hyong Youb Kim ; Beilei Xing ; Qiming Yang >> ; Qi Zhang ; Haiyue Wang ; Matan Azrad >> ; Shahaf Shuler ; Slava Ovsiienko ; NBU-Contact-Thomas >> Monjalon ; Ferruh Yigit ; dev@dpdk.org >> Subject: Re: [PATCH v2] ethdev: fix representor port ID search by name >> >> On 8/28/21 4:22 PM, Xueming(Steven) Li wrote: >>> >>> >>>> -----Original Message----- >>>> From: Viacheslav Galaktionov >>>> Sent: Friday, August 27, 2021 5:48 PM >>>> To: Xueming(Steven) Li >>>> Cc: Andrew Rybchenko ; Ajit Khaparde >>>> ; Somnath Kotur >>>> ; John Daley ; Hyong >>>> Youb Kim ; Beilei Xing ; >>>> Qiming Yang ; Qi Zhang ; >>>> Haiyue Wang ; Matan Azrad ; >>>> Shahaf Shuler ; Slava Ovsiienko >>>> ; NBU-Contact-Thomas Monjalon >>>> ; Ferruh Yigit ; >>>> dev@dpdk.org >>>> Subject: Re: [PATCH v2] ethdev: fix representor port ID search by >>>> name >>>> >>>> On 2021-08-27 12:18, Xueming(Steven) Li wrote: >>>>>> -----Original Message----- >>>>>> From: Andrew Rybchenko >>>>>> Sent: Wednesday, August 18, 2021 10:00 PM >>>>>> To: Ajit Khaparde ; Somnath Kotur >>>>>> ; John Daley ; >>>>>> Hyong Youb Kim ; Beilei Xing >>>>>> ; Qiming Yang ; Qi >>>>>> Zhang ; Haiyue Wang ; >>>>>> Matan Azrad ; Shahaf Shuler ; >>>>>> Slava Ovsiienko ; NBU-Contact-Thomas >>>>>> Monjalon ; Ferruh Yigit >>>>>> >>>>>> Cc: dev@dpdk.org; Viacheslav Galaktionov >>>>>> ; Xueming(Steven) Li >>>>>> >>>>>> Subject: [PATCH v2] ethdev: fix representor port ID search by name >>>>>> >>>>>> From: Viacheslav Galaktionov >>>>>> >>>>>> Getting a list of representors from a representor does not make sense. >>>>>> Instead, a parent device should be used. >>>>>> >>>>>> To this end, extend the rte_eth_dev_data structure to include the >>>>>> port ID of the parent device for representors. >>>>>> >>>>>> Signed-off-by: Viacheslav Galaktionov >>>>>> >>>>>> Signed-off-by: Andrew Rybchenko >>>>>> --- >>>> >>>> [snip] >>>> >>>>>> b/drivers/net/mlx5/windows/mlx5_os.c >>>>>> index 7e1df1c751..0c5a02bfcb 100644 >>>>>> --- a/drivers/net/mlx5/windows/mlx5_os.c >>>>>> +++ b/drivers/net/mlx5/windows/mlx5_os.c >>>>>> @@ -543,6 +543,23 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev, >>>>>> if (priv->representor) { >>>>>> eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR; >>>>>> eth_dev->data->representor_id = priv->representor_id; >>>>>> + MLX5_ETH_FOREACH_DEV(port_id, priv->pci_dev) { >>>>>> + struct mlx5_priv *opriv = >>>>>> + rte_eth_devices[port_id].data->dev_private; >>>>>> + if (opriv && >>>>>> + opriv->master && >>>>>> + opriv->domain_id == priv->domain_id && >>>>>> + opriv->sh == priv->sh) { >>>>>> + eth_dev->data->parent_port_id = >>>>>> + rte_eth_devices[port_id].data->port_id; >>>>> >>>>> Could this value different than port_id? >>>> >>>> Oh, yes, that's an oversight. Thank you! >>>> >>>>>> + break; >>>>>> + } >>>>>> + } >>>>>> + if (port_id >= RTE_MAX_ETHPORTS) { >>>>>> + DRV_LOG(ERR, "no master device for representor"); >>>>>> + err = ENODEV; >>>>>> + goto error; >>>>> >>>>> Here shouldn't be an error. >>>> >>>> What do you mean? Is it normal not to have a master device for a representor? >>> >>> As discussed before, representor could exists w/o master device, special case. >> >> May I clarify one question. Isn't bond will be a parent for the second PF VF representors? Will above algorithm find it? >> If yes, I think we don't need self fallback here. > > Sorry maybe I was not clear enough. It's true that bond will be parent for second PF VF representor, the above algorithm can find it. > But if second PF VF representor probe earlier than the bond, please note that bond get probed with first PF, bond won't be found. > >> If no, it looks a bit wrong to me but may be acceptable for so complicated case. If it is acceptable to you, we can put self fallback here, >> but in this case we don't need corresponding code which check self port_id first. It would be even better this way since generic code >> will be more clear. > > Agree, it's better to make generic ode more clear. Very good. I see your point I'll send v4 tomorrow. >> >>>> >>>>> Parent port ID default to 0, it could be wrong if multiple PF >>>>> probed, let's default to current port ID. >>>> >>>> What is the "current" port ID here? Do you mean the representor's port ID? >>> >>> Representor port ID. >>> >>>> If you are talking about the value of the port_id variable, then I >>>> suppose it could be set to RTE_MAX_ETHPORTS explicitly if a master device isn't found. >>>> >>>> [snip] >