From: Stephen Hemminger <stephen@networkplumber.org>
To: Shani Peretz <shperetz@nvidia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
Tyler Retzlaff <roretzla@linux.microsoft.com>,
Parav Pandit <parav@nvidia.com>, Xueming Li <xuemingl@nvidia.com>,
Nipun Gupta <nipun.gupta@amd.com>,
Nikhil Agarwal <nikhil.agarwal@amd.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>,
Sachin Saxena <sachin.saxena@nxp.com>,
Rosen Xu <rosen.xu@intel.com>, Chenbo Xia <chenbox@nvidia.com>,
Tomasz Duszynski <tduszynski@marvell.com>,
Chengwen Feng <fengchengwen@huawei.com>,
"NBU-Contact-longli (EXTERNAL)" <longli@microsoft.com>,
Wei Hu <weh@microsoft.com>,
Bruce Richardson <bruce.richardson@intel.com>,
Kevin Laatz <kevin.laatz@intel.com>,
Jan Blunck <jblunck@infradead.org>
Subject: Re: [PATCH v4] bus: fix inconsistent representation of PCI numbers
Date: Wed, 5 Feb 2025 10:46:00 -0800 [thread overview]
Message-ID: <20250205104600.3bf2afdc@hermes.local> (raw)
In-Reply-To: <SA1PR12MB9491A6FDB9AD2FC28CC5A0BEBFF72@SA1PR12MB9491.namprd12.prod.outlook.com>
On Wed, 5 Feb 2025 17:37:54 +0000
Shani Peretz <shperetz@nvidia.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger <stephen@networkplumber.org>
> > Sent: Wednesday, 5 February 2025 18:42
> > To: Shani Peretz <shperetz@nvidia.com>
> > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon (EXTERNAL)
> > <thomas@monjalon.net>; Tyler Retzlaff <roretzla@linux.microsoft.com>; Parav
> > Pandit <parav@nvidia.com>; Xueming Li <xuemingl@nvidia.com>; Nipun Gupta
> > <nipun.gupta@amd.com>; Nikhil Agarwal <nikhil.agarwal@amd.com>; Hemant
> > Agrawal <hemant.agrawal@nxp.com>; Sachin Saxena
> > <sachin.saxena@nxp.com>; Rosen Xu <rosen.xu@intel.com>; Chenbo Xia
> > <chenbox@nvidia.com>; Tomasz Duszynski <tduszynski@marvell.com>;
> > Chengwen Feng <fengchengwen@huawei.com>; NBU-Contact-longli
> > (EXTERNAL) <longli@microsoft.com>; Wei Hu <weh@microsoft.com>; Bruce
> > Richardson <bruce.richardson@intel.com>; Kevin Laatz
> > <kevin.laatz@intel.com>; Jan Blunck <jblunck@infradead.org>
> > 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 <shperetz@nvidia.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Stephen Hemminger <stephen@networkplumber.org>
> > > > Sent: Wednesday, 29 January 2025 18:25
> > > > To: Shani Peretz <shperetz@nvidia.com>
> > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon (EXTERNAL)
> > > > <thomas@monjalon.net>; Tyler Retzlaff
> > > > <roretzla@linux.microsoft.com>; Parav Pandit <parav@nvidia.com>;
> > > > Xueming Li <xuemingl@nvidia.com>; Nipun Gupta
> > <nipun.gupta@amd.com>;
> > > > Nikhil Agarwal <nikhil.agarwal@amd.com>; Hemant Agrawal
> > > > <hemant.agrawal@nxp.com>; Sachin Saxena <sachin.saxena@nxp.com>;
> > > > Rosen Xu <rosen.xu@intel.com>; Chenbo Xia <chenbox@nvidia.com>;
> > > > Tomasz Duszynski <tduszynski@marvell.com>; Chengwen Feng
> > > > <fengchengwen@huawei.com>; NBU-Contact-longli
> > > > (EXTERNAL) <longli@microsoft.com>; Wei Hu <weh@microsoft.com>; Bruce
> > > > Richardson <bruce.richardson@intel.com>; Kevin Laatz
> > > > <kevin.laatz@intel.com>; Jan Blunck <jblunck@infradead.org>
> > > > 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 <shperetz@nvidia.com> wrote:
> > > >
> > > > > +create_pci_dev(const char *name)
> > > > > +{
> > > > > + int port_id;
> > > > > + uint8_t slave_mac1[] = {0x00, 0xFF, 0x00, 0xFF, 0x00, 0x00 };
> > > > > + struct rte_ether_addr *mac_addr = (struct rte_ether_addr
> > > > > +*)slave_mac1;
> > > >
> > > > Use different initializer and you can avoid the need for cast here.
> > > >
> > > >
> > > > >
> > > > > +/**
> > > > > + * 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);
> > > >
> > > > It would make more sense to me if name was a character not void pointer.
> > > >
> > > > 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.
> > >
> > >
> > > 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 = {
> > > .addr = da->name,
> > > .size = RTE_DEV_NAME_MAX_LEN
> > > };
> > > dev = 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 = addr;
> > > …
> > > }
> > >
> > > 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
> > >
> >
> > 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.
>
> I think you are right, also it will require to change the signature of find_device which will make it even bigger change
Could you post patch with something "good enough" that builds and passes tests?
next prev parent reply other threads:[~2025-02-05 18:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 20:01 [PATCH] eal/common: " Shani Peretz
2024-07-01 22:00 ` Stephen Hemminger
2024-07-08 16:51 ` [PATCH v3] " Shani Peretz
2024-07-12 13:49 ` David Marchand
2024-07-12 17:55 ` Thomas Monjalon
2025-01-29 8:54 ` [PATCH v4] bus: " Shani Peretz
2025-01-29 9:45 ` Bruce Richardson
2025-01-29 16:25 ` Stephen Hemminger
2025-02-05 16:36 ` Shani Peretz
2025-02-05 16:42 ` Stephen Hemminger
2025-02-05 17:37 ` Shani Peretz
2025-02-05 18:46 ` Stephen Hemminger [this message]
2025-02-05 20:16 ` Shani Peretz
2025-01-29 17:17 ` Stephen Hemminger
2025-01-29 18:06 ` Bruce Richardson
2025-02-05 1:55 ` fengchengwen
2024-10-04 22:21 ` [PATCH] eal/common: " Stephen Hemminger
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=20250205104600.3bf2afdc@hermes.local \
--to=stephen@networkplumber.org \
--cc=bruce.richardson@intel.com \
--cc=chenbox@nvidia.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=hemant.agrawal@nxp.com \
--cc=jblunck@infradead.org \
--cc=kevin.laatz@intel.com \
--cc=longli@microsoft.com \
--cc=nikhil.agarwal@amd.com \
--cc=nipun.gupta@amd.com \
--cc=parav@nvidia.com \
--cc=roretzla@linux.microsoft.com \
--cc=rosen.xu@intel.com \
--cc=sachin.saxena@nxp.com \
--cc=shperetz@nvidia.com \
--cc=tduszynski@marvell.com \
--cc=thomas@monjalon.net \
--cc=weh@microsoft.com \
--cc=xuemingl@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).