DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Xueming(Steven) Li" <xuemingl@nvidia.com>
To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>,
	Somnath Kotur <somnath.kotur@broadcom.com>,
	John Daley <johndale@cisco.com>,
	Hyong Youb Kim <hyonkim@cisco.com>,
	Beilei Xing <beilei.xing@intel.com>,
	Qiming Yang <qiming.yang@intel.com>,
	Qi Zhang <qi.z.zhang@intel.com>,
	Haiyue Wang <haiyue.wang@intel.com>,
	Matan Azrad <matan@nvidia.com>,
	Shahaf Shuler <shahafs@nvidia.com>,
	Slava Ovsiienko <viacheslavo@nvidia.com>,
	NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix representor port ID search by name
Date: Sun, 29 Aug 2021 12:17:04 +0000	[thread overview]
Message-ID: <DM4PR12MB537338AA171582EE982CB709A1CA9@DM4PR12MB5373.namprd12.prod.outlook.com> (raw)
In-Reply-To: <3880ab6a-2b3a-b8ef-bc5e-f6e9b5f43159@oktetlabs.ru>



> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Sunday, August 29, 2021 4:23 PM
> To: Xueming(Steven) Li <xuemingl@nvidia.com>; Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
> Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>; Somnath Kotur <somnath.kotur@broadcom.com>; John Daley
> <johndale@cisco.com>; Hyong Youb Kim <hyonkim@cisco.com>; Beilei Xing <beilei.xing@intel.com>; Qiming Yang
> <qiming.yang@intel.com>; Qi Zhang <qi.z.zhang@intel.com>; Haiyue Wang <haiyue.wang@intel.com>; Matan Azrad
> <matan@nvidia.com>; Shahaf Shuler <shahafs@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>; NBU-Contact-Thomas
> Monjalon <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>; 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 <viacheslav.galaktionov@oktetlabs.ru>
> >> Sent: Friday, August 27, 2021 5:48 PM
> >> To: Xueming(Steven) Li <xuemingl@nvidia.com>
> >> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>; Ajit Khaparde
> >> <ajit.khaparde@broadcom.com>; Somnath Kotur
> >> <somnath.kotur@broadcom.com>; John Daley <johndale@cisco.com>; Hyong
> >> Youb Kim <hyonkim@cisco.com>; Beilei Xing <beilei.xing@intel.com>;
> >> Qiming Yang <qiming.yang@intel.com>; Qi Zhang <qi.z.zhang@intel.com>;
> >> Haiyue Wang <haiyue.wang@intel.com>; Matan Azrad <matan@nvidia.com>;
> >> Shahaf Shuler <shahafs@nvidia.com>; Slava Ovsiienko
> >> <viacheslavo@nvidia.com>; NBU-Contact-Thomas Monjalon
> >> <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>;
> >> 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 <andrew.rybchenko@oktetlabs.ru>
> >>>> Sent: Wednesday, August 18, 2021 10:00 PM
> >>>> To: Ajit Khaparde <ajit.khaparde@broadcom.com>; Somnath Kotur
> >>>> <somnath.kotur@broadcom.com>; John Daley <johndale@cisco.com>;
> >>>> Hyong Youb Kim <hyonkim@cisco.com>; Beilei Xing
> >>>> <beilei.xing@intel.com>; Qiming Yang <qiming.yang@intel.com>; Qi
> >>>> Zhang <qi.z.zhang@intel.com>; Haiyue Wang <haiyue.wang@intel.com>;
> >>>> Matan Azrad <matan@nvidia.com>; Shahaf Shuler <shahafs@nvidia.com>;
> >>>> Slava Ovsiienko <viacheslavo@nvidia.com>; NBU-Contact-Thomas
> >>>> Monjalon <thomas@monjalon.net>; Ferruh Yigit
> >>>> <ferruh.yigit@intel.com>
> >>>> Cc: dev@dpdk.org; Viacheslav Galaktionov
> >>>> <viacheslav.galaktionov@oktetlabs.ru>; Xueming(Steven) Li
> >>>> <xuemingl@nvidia.com>
> >>>> Subject: [PATCH v2] ethdev: fix representor port ID search by name
> >>>>
> >>>> From: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
> >>>>
> >>>> 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
> >>>> <viacheslav.galaktionov@oktetlabs.ru>
> >>>> Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> >>>> ---
> >>
> >> [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.

> 
> >>
> >>> 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]


  reply	other threads:[~2021-08-29 12:17 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-12 16:17 [dpdk-dev] [PATCH] " Andrew Rybchenko
2021-07-19  6:58 ` Xueming(Steven) Li
2021-07-19  8:46   ` Andrew Rybchenko
2021-07-19 11:54     ` Xueming(Steven) Li
2021-07-19 12:36       ` Andrew Rybchenko
2021-07-19 12:50         ` Xueming(Steven) Li
2021-07-20  8:59           ` Andrew Rybchenko
2021-07-29  4:13             ` Xueming(Steven) Li
2021-08-01  8:40               ` Andrew Rybchenko
2021-08-01 14:25                 ` Xueming(Steven) Li
2021-07-29  4:20 ` Xueming(Steven) Li
2021-08-01  8:50   ` Andrew Rybchenko
2021-08-01 14:15     ` Xueming(Steven) Li
2021-08-18 14:00 ` [dpdk-dev] [PATCH v2] " Andrew Rybchenko
2021-08-27  9:18   ` Xueming(Steven) Li
2021-08-27  9:48     ` Viacheslav Galaktionov
2021-08-28 13:22       ` Xueming(Steven) Li
2021-08-29  8:23         ` Andrew Rybchenko
2021-08-29 12:17           ` Xueming(Steven) Li [this message]
2021-08-31 15:42             ` Andrew Rybchenko
2021-08-20 12:18 ` [dpdk-dev] [PATCH v3] " Andrew Rybchenko
2021-08-31 15:41   ` Andrew Rybchenko
2021-08-31 16:06 ` [dpdk-dev] [PATCH v4] " Andrew Rybchenko
2021-08-31 16:32   ` Wang, Haiyue
2021-08-31 16:37     ` Andrew Rybchenko
2021-09-01  5:15   ` Xing, Beilei
2021-09-01 14:55   ` Ferruh Yigit
2021-09-06 16:16     ` Viacheslav Galaktionov
2021-09-13 11:26 ` [dpdk-dev] [PATCH v5] " Andrew Rybchenko
2021-09-29 11:13   ` Singh, Aman Deep
2021-09-30 12:03     ` Andrew Rybchenko
2021-09-30 12:51       ` Singh, Aman Deep
2021-09-30 13:40         ` Andrew Rybchenko
2021-10-01 11:39   ` Andrew Rybchenko
2021-10-08  8:39     ` Xueming(Steven) Li
2021-10-05 21:56   ` Thomas Monjalon
2021-10-07 10:20     ` Andrew Rybchenko
2021-10-07 12:39       ` Thomas Monjalon
2021-10-08  9:27 ` [dpdk-dev] [PATCH v6] " Andrew Rybchenko
2021-10-11  7:56   ` Slava Ovsiienko
2021-10-11 12:30 ` [dpdk-dev] [PATCH v7] " Andrew Rybchenko
2021-10-11 12:53 ` [dpdk-dev] [PATCH v8] " Andrew Rybchenko
2021-10-12 15:09   ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM4PR12MB537338AA171582EE982CB709A1CA9@DM4PR12MB5373.namprd12.prod.outlook.com \
    --to=xuemingl@nvidia.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=haiyue.wang@intel.com \
    --cc=hyonkim@cisco.com \
    --cc=johndale@cisco.com \
    --cc=matan@nvidia.com \
    --cc=qi.z.zhang@intel.com \
    --cc=qiming.yang@intel.com \
    --cc=shahafs@nvidia.com \
    --cc=somnath.kotur@broadcom.com \
    --cc=thomas@monjalon.net \
    --cc=viacheslav.galaktionov@oktetlabs.ru \
    --cc=viacheslavo@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).