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 C56D5461A2; Thu, 6 Feb 2025 01:40:18 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 16846402A0; Thu, 6 Feb 2025 01:40:18 +0100 (CET) Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by mails.dpdk.org (Postfix) with ESMTP id DD3854029E for ; Thu, 6 Feb 2025 01:40:16 +0100 (CET) Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-2161eb95317so7724215ad.1 for ; Wed, 05 Feb 2025 16:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1738802415; x=1739407215; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=dUp6TQs5o7R2S2PGtXTayqoK9jJHorMuKuFROFi6PIQ=; b=qKENEN6pO8SBk1dtlKmetras6SqJKFy05IwZulnJM4AIahAv1fDibA5G3XYXeLc92u dPAzKaSPJaagiu98y5szgZWeX1HmPYxHZps6PRrL8WgvDf9TNJT4YudMSO79TRhsDPU9 Zbrth39KVkCk98rsqTn28A57W5Ft/ohaWgHJEY4zIwRsk29aOogGrliEyJuJ9nw23Xy2 K5rD9YkmGoRrZK6NnytLbiwwJWiYA8E1J6zOjWlsbvt7vVg7of3/adkM/RGfFEL6tWlF JI56SpilZOCyt2G+xsAQLzSP14uf6g3Fw8tQ3UZ1E8J9AdVgcV3iymZzB6iV+vTzPpsm lvEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738802415; x=1739407215; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dUp6TQs5o7R2S2PGtXTayqoK9jJHorMuKuFROFi6PIQ=; b=lurdig2ak45Qh050/nXV+VLfqjml4cYXFeKStBdvOYimbXCOAKr/Y3wsbU7ZqA7Q4W xTlyz+bGHhnoGK5UyFik/3ClJLUJJGd4SNpAr4PdCMzDscc9vQdeQfF8XlxD5piI9kxz ao7l+kRg4dOTnSQVPV0dsdMkpskIfUYaUU+7jFSV0N/SzlBaoEiFlx0bY5rlq2PLTJ9h OJn1vdFLpSvSWsnBjhfxrq2gBAKTgZCxQHcxf8uW+0ZFfCwSiyvkuOIKLVnam7aqLo+L aAYkZwor82LtXWWXyu3FnPhTwISke7CjAswa8DLqJZ83vlSOBzb9fO61IWwz6LDUCVhV UTcg== X-Gm-Message-State: AOJu0YyObQuO1zJu/CirJmE51ghebOFZC8b3LN9mLN6zoa5RJLosvBWi rpQZpet0c88GhaDRsvfM91MBV/BmSm8Vo+cTn+mvNg7zodcqHcKAD20DNoMJYsU= X-Gm-Gg: ASbGncsHh8IMe8Vwx7ZxyJ209gVFIXkvk2y7LKAYUkSk4f9Se2mzf+C+xd7O7azN8Jf +fogmNWzxDxKlIO6L6ouWmqHS5LWsSYK7y3qK4yviZntOuKoyzgWDUBKSha3Vf+AwI3nCTuQ4CH qWu1Cb40LCKA80pjocAl2b0+H939/r7UZzZup94iiNnugHK0aObfDJ7E9pWFucQzUV0nQT2PlA2 f+tx7hzs4FqrIgEGXZRQPLacGzrCiGWFbhd0kWP4cGFqTaiptgNzJOyYdUtqv2mpwvOVkYbIE58 ToXKKRNYhPN50zWplNbGB//NrIhZ5N4br8LPz3uJwqQdzkxTkOFmjlryfAfyuwyCDz50 X-Google-Smtp-Source: AGHT+IGzBLoyvhNj13aWIV+yp6FoZnp69z+b5vf5vNpY8qqDWfviXbOIJ4VWWc5H5F1AJ9uHSMirbg== X-Received: by 2002:a17:902:f550:b0:208:d856:dbb7 with SMTP id d9443c01a7336-21f17ebac0bmr82215145ad.39.1738802415629; Wed, 05 Feb 2025 16:40:15 -0800 (PST) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21f3687c674sm62675ad.181.2025.02.05.16.40.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Feb 2025 16:40:15 -0800 (PST) Date: Wed, 5 Feb 2025 16:40:13 -0800 From: Stephen Hemminger To: Shani Peretz Cc: "dev@dpdk.org" , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Tyler Retzlaff , Parav Pandit , Xueming Li , Nipun Gupta , Nikhil Agarwal , Hemant Agrawal , Sachin Saxena , Rosen Xu , Chenbo Xia , Tomasz Duszynski , Chengwen Feng , "NBU-Contact-longli (EXTERNAL)" , Wei Hu , Bruce Richardson , Kevin Laatz , Jan Blunck Subject: Re: [PATCH v4] bus: fix inconsistent representation of PCI numbers Message-ID: <20250205164013.4e692f36@hermes.local> In-Reply-To: References: <20240708165145.1405107-1-shperetz@nvidia.com> <20250129085416.226718-1-shperetz@nvidia.com> <20250129082518.47630942@hermes.local> <20250205084202.264d9781@hermes.local> <20250205104600.3bf2afdc@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 On Wed, 5 Feb 2025 20:16:48 +0000 Shani Peretz wrote: > > -----Original Message----- > > From: Stephen Hemminger > > Sent: Wednesday, 5 February 2025 20:46 > > To: Shani Peretz > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon (EXTERNAL) > > ; Tyler Retzlaff ; P= arav > > Pandit ; Xueming Li ; Nipun Gupta > > ; Nikhil Agarwal ; Hemant > > Agrawal ; Sachin Saxena > > ; Rosen Xu ; Chenbo Xia > > ; Tomasz Duszynski ; > > Chengwen Feng ; NBU-Contact-longli > > (EXTERNAL) ; Wei Hu ; Bruce > > Richardson ; Kevin Laatz > > ; Jan Blunck > > Subject: Re: [PATCH v4] bus: fix inconsistent representation of PCI num= bers > >=20 > > External email: Use caution opening links or attachments > >=20 > >=20 > > On Wed, 5 Feb 2025 17:37:54 +0000 > > Shani Peretz wrote: > > =20 > > > > -----Original Message----- > > > > From: Stephen Hemminger > > > > Sent: Wednesday, 5 February 2025 18:42 > > > > To: Shani Peretz > > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon (EXTERNAL) > > > > ; Tyler Retzlaff > > > > ; Parav Pandit ; > > > > Xueming Li ; Nipun Gupta =20 > > ; =20 > > > > Nikhil Agarwal ; Hemant Agrawal > > > > ; Sachin Saxena ; > > > > Rosen Xu ; Chenbo Xia ; > > > > Tomasz Duszynski ; Chengwen Feng > > > > ; NBU-Contact-longli > > > > (EXTERNAL) ; Wei Hu ; Bruce > > > > Richardson ; Kevin Laatz > > > > ; Jan Blunck > > > > Subject: Re: [PATCH v4] bus: fix inconsistent representation of PCI > > > > numbers > > > > > > > > External email: Use caution opening links or attachments > > > > > > > > > > > > On Wed, 5 Feb 2025 16:36:11 +0000 > > > > Shani Peretz wrote: > > > > =20 > > > > > > -----Original Message----- > > > > > > From: Stephen Hemminger > > > > > > Sent: Wednesday, 29 January 2025 18:25 > > > > > > To: Shani Peretz > > > > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon (EXTERNAL) > > > > > > ; Tyler Retzlaff > > > > > > ; Parav Pandit ; > > > > > > Xueming Li ; Nipun Gupta =20 > > > > ; =20 > > > > > > Nikhil Agarwal ; Hemant Agrawal > > > > > > ; Sachin Saxena ; > > > > > > Rosen Xu ; Chenbo Xia ; > > > > > > Tomasz Duszynski ; Chengwen Feng > > > > > > ; NBU-Contact-longli > > > > > > (EXTERNAL) ; Wei Hu ; > > > > > > Bruce Richardson ; Kevin Laatz > > > > > > ; Jan Blunck > > > > > > Subject: Re: [PATCH v4] bus: fix inconsistent representation of > > > > > > PCI numbers > > > > > > > > > > > > External email: Use caution opening links or attachments > > > > > > > > > > > > > > > > > > On Wed, 29 Jan 2025 10:54:16 +0200 Shani Peretz > > > > > > wrote: > > > > > > =20 > > > > > > > +create_pci_dev(const char *name) { > > > > > > > + int port_id; > > > > > > > + uint8_t slave_mac1[] =3D {0x00, 0xFF, 0x00, 0xFF, 0x00,= 0x00 }; > > > > > > > + struct rte_ether_addr *mac_addr =3D (struct rte_ether_a= ddr > > > > > > > +*)slave_mac1; =20 > > > > > > > > > > > > Use different initializer and you can avoid the need for cast h= ere. > > > > > > > > > > > > =20 > > > > > > > > > > > > > > +/** > > > > > > > + * General device name comparison. Will compare by using the > > > > > > > +specific bus > > > > > > > + * compare function or by comparing the names directly. > > > > > > > + * > > > > > > > + * @param dev > > > > > > > + * Device handle. > > > > > > > + * @param name > > > > > > > + * Name to compare against. > > > > > > > + * @return > > > > > > > + * 0 if the device matches the name. Nonzero otherwise. > > > > > > > + */ > > > > > > > +__rte_internal > > > > > > > +int rte_cmp_dev_name(const struct rte_device *dev, const void > > > > > > > +*name); =20 > > > > > > > > > > > > It would make more sense to me if name was a character not void= =20 > > pointer. =20 > > > > > > > > > > > > The design might be clearer if bus address was more of an > > > > > > typedef with a pointer and size together. Treat it more like an= object. =20 > > > > > > > > > > > > > > > Okay so just to understand, > > > > > this is the struct I am adding: > > > > > > > > > > struct rte_bus_address { > > > > > const void *addr; > > > > > size_t size; > > > > > }; > > > > > > > > > > This is how I pass it to find_device: > > > > > > > > > > struct rte_bus_address dev_addr =3D { > > > > > .addr =3D da->name, > > > > > .size =3D RTE_DEV_NAME_MAX_LEN > > > > > }; > > > > > dev =3D da->bus->find_device(NULL, rte_cmp_dev_name, > > > > > &dev_addr); > > > > > > > > > > And this is how I use it in rte_cmp_dev_name: > > > > > > > > > > rte_cmp_dev_name(const struct rte_device *dev1, const void = *addr) > > > > > { > > > > > const struct rte_bus_address *dev2_addr =3D addr; > > > > > =E2=80=A6 > > > > > } > > > > > > > > > > Is that what you meant? > > > > > Also, I'm not sure if the size is really needed, because we check > > > > > the size of the parsed name, which may be different than the size > > > > > of the original name > > > > > =20 > > > > > > > > It would be best to pass rte_bus_address to rte_cmp_dev_name rather > > > > than having implied cast. > > > > Not sure if that is possible without breaking API though. =20 > > > > > > I think you are right, also it will require to change the signature of > > > find_device which will make it even bigger change =20 > >=20 > > Could you post patch with something "good enough" that builds and passes > > tests? =20 >=20 > You mean with the rte_bus_address change or without? > Without it it was tested and passed. With it I only ran few tests locally= and they passed With the bus address change how much impact? Not sure it really matter much= though both solutions are ok, it is more about dealing with other buses in future.