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 CC143A0C4C; Sun, 29 Aug 2021 10:23:07 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5419740142; Sun, 29 Aug 2021 10:23:07 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 92B7C40042 for ; Sun, 29 Aug 2021 10:23: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) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id A6BB87F53D; Sun, 29 Aug 2021 11:23:05 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru A6BB87F53D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1630225385; bh=OF802lCm0z4h9mY9aVtlD1hI1moBf8O0/N3GSya8usg=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=YP0iTQtkSudP3GYER2x0I8S9h/WKT9+ire5LNcc3clr3284L7uSMv4ZGTO7p4h4Qr kpnCRBvOK6iqNNXhjyfXs3baUm5qcioArey3S7K8LsfuXBSuzIspQwoyhBbMqi40PJ YVSjEN/8vXECv73vlNjCX+eQxsRoRSPklclOXYlI= 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> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <3880ab6a-2b3a-b8ef-bc5e-f6e9b5f43159@oktetlabs.ru> Date: Sun, 29 Aug 2021 11:23: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/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. 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. >> >>> 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]